Re: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description
Sorry for spamming...
I noticed that the previous patch would break user provided rpm spec files
so I'm attaching a new patch that fixes that problem with a bit more
variable juggling.
I also have a question. Would CPack also need something like
CPACK_COMPONENT_component_PACKAGE_SUMMARY that could be used by
CPACK_RPM_component_PACKAGE_SUMMARY as default value?
Thanks,
Domen
2014-10-14 0:23 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:
Message was sent to early by accident so I'm resending the rest.
2014-10-14 0:17 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:
Hi,
I extended the proposed patch for ticket 13176 with:
- documentation section
- CPACK_RPM_component_PACKAGE_DESCRIPTION fallback to
CPACK_COMPONENT_compName_DESCRIPTION
- handling of cases when one component sets its variable and the other
doesn't
e.g.
#set(CPACK_RPM_test_PACKAGE_SUMMARY test_summary)
set(CPACK_RPM_bin_PACKAGE_SUMMARY bin_summary)
Could somebody please review the patch attached to this mail?
Regards,
Domen
From 5c229cd048086f3d6413ade0ba0e317c869036f8 Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Tue, 14 Oct 2014 07:57:11 +0200
Subject: [PATCH] CPackRPM component based packaging description and summary
Enables per component description and summary setting through
CPACK_RPM_component_PACKAGE_DESCRIPTION,
CPACK_COMPONENT_compName_DESCRIPTION
and CPACK_RPM_component_PACKAGE_SUMMARY variables
---
Modules/CPackRPM.cmake | 77 ++
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 2864b21..bab5c83 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -29,6 +29,7 @@
# However as a handy reminder here comes the list of specific variables:
#
# .. variable:: CPACK_RPM_PACKAGE_SUMMARY
+# CPACK_RPM_component_PACKAGE_SUMMARY
#
# The RPM package summary.
#
@@ -100,11 +101,13 @@
# * Default : -
#
# .. variable:: CPACK_RPM_PACKAGE_DESCRIPTION
+# CPACK_RPM_component_PACKAGE_DESCRIPTION
#
# RPM package description.
#
# * Mandatory : YES
-# * Default : CPACK_PACKAGE_DESCRIPTION_FILE if set or no package
+# * Default : CPACK_COMPONENT_compName_DESCRIPTION (component based installers
+#only) if set, CPACK_PACKAGE_DESCRIPTION_FILE if set or no package
#description available
#
# .. variable:: CPACK_RPM_COMPRESSION_TYPE
@@ -430,12 +433,31 @@ set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACK
#
# CPACK_RPM_PACKAGE_SUMMARY (mandatory)
+
+# CPACK_RPM_PACKAGE_SUMMARY_ is used only locally so that it can be unset each time before use otherwise
+# component packaging could leak variable content between components
+unset(CPACK_RPM_PACKAGE_SUMMARY_)
+if(CPACK_RPM_PACKAGE_SUMMARY)
+ set(CPACK_RPM_PACKAGE_SUMMARY_ ${CPACK_RPM_PACKAGE_SUMMARY})
+ unset(CPACK_RPM_PACKAGE_SUMMARY)
+endif()
+
+#Check for component summary first.
+#If not set, it will use regular package summary logic.
+if(CPACK_RPM_PACKAGE_COMPONENT)
+ if(CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_SUMMARY)
+set(CPACK_RPM_PACKAGE_SUMMARY ${CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_SUMMARY})
+ endif()
+endif()
+
if(NOT CPACK_RPM_PACKAGE_SUMMARY)
- # if neither var is defined lets use the name as summary
- if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
-string(TOLOWER ${CPACK_PACKAGE_NAME} CPACK_RPM_PACKAGE_SUMMARY)
- else()
+ if(CPACK_RPM_PACKAGE_SUMMARY_)
+set(CPACK_RPM_PACKAGE_SUMMARY ${CPACK_RPM_PACKAGE_SUMMARY_})
+ elseif(CPACK_PACKAGE_DESCRIPTION_SUMMARY)
set(CPACK_RPM_PACKAGE_SUMMARY ${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+ else()
+# if neither var is defined lets use the name as summary
+string(TOLOWER ${CPACK_PACKAGE_NAME} CPACK_RPM_PACKAGE_SUMMARY)
endif()
endif()
@@ -508,12 +530,33 @@ endif()
# if it is defined
# - set to a default value
#
-if (NOT CPACK_RPM_PACKAGE_DESCRIPTION)
-if (CPACK_PACKAGE_DESCRIPTION_FILE)
-file(READ ${CPACK_PACKAGE_DESCRIPTION_FILE} CPACK_RPM_PACKAGE_DESCRIPTION)
-else ()
-set(CPACK_RPM_PACKAGE_DESCRIPTION no package description available)
-endif ()
+
+# CPACK_RPM_PACKAGE_DESCRIPTION_ is used only locally so that it can be unset each time before use otherwise
+# component packaging could leak variable content between components
+unset(CPACK_RPM_PACKAGE_DESCRIPTION_)
+if(CPACK_RPM_PACKAGE_DESCRIPTION)
+ set(CPACK_RPM_PACKAGE_DESCRIPTION_ ${CPACK_RPM_PACKAGE_DESCRIPTION})
+ unset(CPACK_RPM_PACKAGE_DESCRIPTION)
+endif()
+
+#Check for a component description first.
+#If not set, it will use regular package description logic.
+if(CPACK_RPM_PACKAGE_COMPONENT)
+ if(CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_DESCRIPTION)
+set(CPACK_RPM_PACKAGE_DESCRIPTION ${CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_DESCRIPTION})
+
Re: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description
2014-10-14 9:03 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Sorry for spamming... I noticed that the previous patch would break user provided rpm spec files so I'm attaching a new patch that fixes that problem with a bit more variable juggling. Hi Domen, I did re-assign the bug entry to you http://public.kitware.com/Bug/view.php?id=13176 Then we discussing various patches I suggest you to attach the patch directly to the tracker that way it's easy to see the patch history and if ever some patch version is obsolete you may simply remove it from the tracker. I also have a question. Would CPack also need something like CPACK_COMPONENT_component_PACKAGE_SUMMARY that could be used by CPACK_RPM_component_PACKAGE_SUMMARY as default value? Not sure of that one. We already have CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION which may be a default value for CPACK_RPM_component_PACKAGE_ SUMMARY if packaging is done by compoent group (which is the default): The behavior of the various CPack generator w.r.t. mono- or multi- file/package generation vary, see: http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior e.g. for NSIS or PackageMaker I don't know what you can do with CPACK_COMPONENT_component_ PACKAGE_SUMMARY because there is only one package. Otherwise I only read the patch and it looks good. However you should at least: 1) run ctest -R CPack -- this the minimal way to run CPack related tests in the CMake tree 2) enhance or provide a specific test for the new behavior. Eric Thanks, Domen 2014-10-14 0:23 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Message was sent to early by accident so I'm resending the rest. 2014-10-14 0:17 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Hi, I extended the proposed patch for ticket 13176 with: - documentation section - CPACK_RPM_component_PACKAGE_DESCRIPTION fallback to CPACK_COMPONENT_compName_DESCRIPTION - handling of cases when one component sets its variable and the other doesn't e.g. #set(CPACK_RPM_test_PACKAGE_SUMMARY test_summary) set(CPACK_RPM_bin_PACKAGE_SUMMARY bin_summary) Could somebody please review the patch attached to this mail? Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description
2014-10-14 9:28 GMT+02:00 Eric Noulard eric.noul...@gmail.com: 2014-10-14 9:03 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Sorry for spamming... I noticed that the previous patch would break user provided rpm spec files so I'm attaching a new patch that fixes that problem with a bit more variable juggling. Hi Domen, I did re-assign the bug entry to you http://public.kitware.com/Bug/view.php?id=13176 Noticed that. Thanks. I did not notice that I can reassign bugs myself. Then we discussing various patches I suggest you to attach the patch directly to the tracker that way it's easy to see the patch history and if ever some patch version is obsolete you may simply remove it from the tracker. Done. I also have a question. Would CPack also need something like CPACK_COMPONENT_component_PACKAGE_SUMMARY that could be used by CPACK_RPM_component_PACKAGE_SUMMARY as default value? Not sure of that one. We already have CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION which may be a default value for CPACK_RPM_component_PACKAGE_ SUMMARY if packaging is done by compoent group (which is the default): The behavior of the various CPack generator w.r.t. mono- or multi- file/package generation vary, see: http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior I'll read it in the afternoon. e.g. for NSIS or PackageMaker I don't know what you can do with CPACK_COMPONENT_component_ PACKAGE_SUMMARY because there is only one package. Otherwise I only read the patch and it looks good. However you should at least: 1) run ctest -R CPack -- this the minimal way to run CPack related tests in the CMake tree Forgot to run the tests the first time but remembered afterwards. 2) enhance or provide a specific test for the new behavior. Will do this in the afternoon. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Preparing for CMake 3.1.0-rc1
On 10/03/2014 08:27 AM, Brad King wrote: please refrain from adding non-trivial changes in the meantime. I've branched 'release' for 3.1. The repository is now open for post-3.1 development. Please rebase any open topics on 'master' before merging to 'next'. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support
On 10/09/2014 07:36 PM, Geoffrey Viola wrote:
Attached is a patch to make CMake generate files for the Green
Hills MULTI IDE. These patches are in reference to this feature
request: http://public.kitware.com/Bug/view.php?id=14992.
Thanks for working on this.
First I've extracted the comment typo fixes from the second patch:
Fix some spelling errors in comments
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81
I've attached a patch rebasing the rest of the changes on 'master'
after integration of the typo fixes.
To aid others for review, please provide a high-level explanation
of the MULTI IDE, its target platforms, and how developers might
use it with CMake.
There were some limitations. It has been restricted to Windows,
because that is the version of the IDE that I have. There is a
special grouping called a Monolith that includes several
executables, shared libraries, and the kernel. These monoliths
have their own set of compile options. I’m not sure how CMake
would be able to create these. Also, there are some internal
macros that point to the compiler’s target BSP and OS that are
currently populated via CMake variables: GHS_CUSTOMIZATION,
GHS_OS_DIR, and GHS_BSP_NAME.
Depending on the semantics, these may belong in
Modules/Platform/os.cmake for some os name of the target
platform. We'll need a better understanding of their role to
say for sure though. See CMAKE_OSX_SYSROOT in Darwin*.cmake
for example.
Thanks,
-Brad
From 2a6c15be56d938d1fac6a06ef9acb06ceeec1e67 Mon Sep 17 00:00:00 2001
Message-Id: 2a6c15be56d938d1fac6a06ef9acb06ceeec1e67.1413294735.git.brad.k...@kitware.com
From: Geoff Viola geoffrey.vi...@autonomoussolutions.com
Date: Thu, 9 Oct 2014 17:07:48 -0600
Subject: [PATCH] Added basic and partial support for a Green Hill MULTI IDE.
---
Modules/CMakeGreenHillsFindMake.cmake | 25 +++
Source/CMakeLists.txt | 6 +
Source/cmGhsMultiTargetGenerator.cxx | 301 ++
Source/cmGhsMultiTargetGenerator.h| 74
Source/cmGlobalGhsMultiGenerator.cxx | 338 ++
Source/cmGlobalGhsMultiGenerator.h| 104 +++
Source/cmLocalGhsMultiGenerator.cxx | 56 ++
Source/cmLocalGhsMultiGenerator.h | 56 ++
Source/cmake.cxx | 4 +
9 files changed, 964 insertions(+)
create mode 100644 Modules/CMakeGreenHillsFindMake.cmake
create mode 100644 Source/cmGhsMultiTargetGenerator.cxx
create mode 100644 Source/cmGhsMultiTargetGenerator.h
create mode 100644 Source/cmGlobalGhsMultiGenerator.cxx
create mode 100644 Source/cmGlobalGhsMultiGenerator.h
create mode 100644 Source/cmLocalGhsMultiGenerator.cxx
create mode 100644 Source/cmLocalGhsMultiGenerator.h
diff --git a/Modules/CMakeGreenHillsFindMake.cmake b/Modules/CMakeGreenHillsFindMake.cmake
new file mode 100644
index 000..7af9f18
--- /dev/null
+++ b/Modules/CMakeGreenHillsFindMake.cmake
@@ -0,0 +1,25 @@
+
+#=
+# Copyright 2005-2009 Kitware, Inc.
+#
+# Distributed under the OSI-approved BSD License (the License);
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+# License text for the above reference.)
+# set(CMAKE_CROSSCOMPILING TRUE)
+
+set(CMAKE_SYSTEM_NAME Green Hills MULTI)
+set(CMAKE_SYSTEM_PROCESSOR ARM)
+find_program(CMAKE_MAKE_PROGRAM gbuild.exe PATHS
+[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\GreenHillsSoftware9881cef6;InstallLocation]
+c:/ghs/comp_.*
+)
+string(REGEX MATCH (comp_)([0-9]+) CMAKE_SYSTEM_VERSION ${CMAKE_MAKE_PROGRAM})
+string(REPLACE comp_ CMAKE_SYSTEM_VERSION ${CMAKE_SYSTEM_VERSION})
+
+mark_as_advanced(CMAKE_MAKE_PROGRAM)
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index f9405b3..df642d5 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -446,6 +446,12 @@ if (WIN32)
cmVisualStudioSlnParser.cxx
cmVisualStudioWCEPlatformParser.h
cmVisualStudioWCEPlatformParser.cxx
+ cmGlobalGhsMultiGenerator.cxx
+ cmGlobalGhsMultiGenerator.h
+ cmLocalGhsMultiGenerator.cxx
+ cmLocalGhsMultiGenerator.h
+ cmGhsMultiTargetGenerator.cxx
+ cmGhsMultiTargetGenerator.h
)
endif()
endif ()
diff --git a/Source/cmGhsMultiTargetGenerator.cxx b/Source/cmGhsMultiTargetGenerator.cxx
new file mode 100644
index 000..9a955bc
--- /dev/null
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -0,0 +1,301 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2011 Peter
Re: [cmake-developers] [CMake] Forcing colorization of output from cmake
On 10/09/2014 01:38 PM, Paul Smith wrote:
What I really want is that if MAKE_TERMOUT is set to a non-empty value,
cmake should pretend that it's in a terminal regardless of what isatty()
says. We can do this easily enough by adding a simple test to
Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
anywhere else:
One problem with this is that non-make processes launched by make may
run their own children to capture the output through pipes and not
unset MAKE_TERMOUT. We need it to be 'make' that evaluates that env
variable. Your original command-line approach did this.
In a way this is gross, certainly, but this function already checks for
environment variable such as TERM, EMACS, etc. which are set by calling
utilities and handles them specially. So why not MAKE_TERMOUT as well?
The TERM and EMACS variables are checked to determine whether the
terminal supports color when isatty() returns true. That is not
the same as forcing tty behavior.
I would expect FORCE to be stronger than that, and return
true regardless of TERM settings.
Okay, but the internal API in KWSys Terminal needs to be more granular
than that. Please revise your patch to use my KWSys part but also
add a ForceVT100 setting that causes TERM and EMACS to be ignored.
Then the --switch=FORCE can set both the ForceTTY and ForceVT100
setting internally.
I'm not at all familiar with Windows so I have no strong opinions on
whether FORCE should also force color output on a Windows console...
although I know a number of people who do use GNU make on Windows and
the Windows port of GNU make does set MAKE_TERMOUT properly.
Native Windows terminals do not support the color escape sequences
at all. We need to get a handle to the underlying console buffer and
set parameters on it directly. If the output pipe is not connected
to a real console then we cannot get the console handle and print
color at all.
We already have a CMAKE_COLOR_MAKEFILE option. Perhaps instead
of just ON or OFF values it could have a GNU value that enables
Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
we can run it to test the output of ${CMAKE_MAKE_PROGRAM} --version.
The question is, what do you do in the generated makefile if you see
that it's GNU make?
The CMake generator would recognize CMAKE_COLOR_MAKEFILE==GNU and
enable the GNU-specific content. CMAKE_COLOR_MAKEFILE is a cache
setting the user could set if they don't like the default. We can
set the default based on whether the CMAKE_MAKE_PROGRAM is GNU.
It would need to be the equivalent of:
--switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))
to preserve the current behavior, where the COLOR variable setting can
be inherited from the environment.
Yes.
What if someone runs cmake and it detects GNU make, but then they run
/my/other/make which is not GNU make? That would work fine now but
fail if we generated GNU-specific content in 'Unix Makefiles'
generators.
The user could always set CMAKE_COLOR_MAKEFILE to ON instead of GNU
to work with other make tools.
If we had a different generator, like 'GNU Makefiles' for example, then
people who chose that would clearly expect the results would only work
with GNU make, but we don't have that.
One day we may create a 'GNU Makefiles' generator to enable use of
GNU-specific features, but that would need to be a more comprehensive
effort than just changing the color option.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015207]: FindJNI does not work when compiling 32-bit target on 64-bit host
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15207 == Reported By:Stepan Schejbal Assigned To: == Project:CMake Issue ID: 15207 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-10-14 10:31 EDT Last Modified: 2014-10-14 10:31 EDT == Summary:FindJNI does not work when compiling 32-bit target on 64-bit host Description: When compiling 32-bit linux target using -m32, FindJNI breaks, because it is based on CMAKE_SYSTEM_PROCESSOR which does not match the target architecture. This is related to issue http://public.kitware.com/Bug/view.php?id=9611. Steps to Reproduce: find_package(JNI REQUIRED) export CC=gcc-4.8 export CXX=g++-4.8 export JAVA_HOME=/opt/jdk1.7.0_55-i586 export CFLAGS=-m32 export CXXFLAGS=-m32 export LDFALGS=-m32 cmake... == Issue History Date ModifiedUsername FieldChange == 2014-10-14 10:31 Stepan SchejbalNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Adam Strzelecki wrote: What makes this a Qt issue instead of a generic issue? $ git show 9b98fd52 [Ignoring the qt.conf part] Again, what is Qt-specific about bundling a plugin with an application? What is non-generic about that? Why can't CMake targets communicate what needs to be bundled with them? Why can't some CMake interface consume such information? Why would a install_qt5_bundle function bundle only the platform plugin, but not other plugins? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support
Green Hills MULTI is an IDE for embedded real-time systems. It features an editor, a great debugger, and a GUI to organize and visual memory layouts: http://www.ghs.com/products/MULTI_IDE.html. There is a Linux and Windows version of it. Green Hill's real-time operating system, INTEGRITY, supports ARM, Intel x86, and other architectures: http://www.ghs.com/products/rtos/integrity.html. It is advantageous to use CMake for its script based target management functionality, which is very useful to manage unit tests, and 3rd party finding mechanisms. Switching between IDEs is advantageous because other IDEs have better editors and built-in support to run unit tests. Also, embedded code could be ported to ease debugging without extra hardware. I took a look at CMAKE_OSX_SYSROOT. It is similar to GHS_OS_DIR. There may be a simpler way to represent these customizations, but I don't know if there are any guarantees on standard folder structures or names. The current patch is being used to create all the main targets and a default top level file. That generated top level file is hand edited to include custom hand edited kernel and monolith files. It is my intention to generate everything via CMake. It seems there needs to be some development to use the find boost module, because CMAKE_FIND_LIBRARY_PREFIXES is not set. Geoffrey Viola SOFTWARE ENGINEER T +1.435.755.2980 ext 1077 M +1.215.896.6521 asirobots.com -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, October 14, 2014 7:57 AM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 10/09/2014 07:36 PM, Geoffrey Viola wrote: Attached is a patch to make CMake generate files for the Green Hills MULTI IDE. These patches are in reference to this feature request: http://public.kitware.com/Bug/view.php?id=14992. Thanks for working on this. First I've extracted the comment typo fixes from the second patch: Fix some spelling errors in comments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81 I've attached a patch rebasing the rest of the changes on 'master' after integration of the typo fixes. To aid others for review, please provide a high-level explanation of the MULTI IDE, its target platforms, and how developers might use it with CMake. There were some limitations. It has been restricted to Windows, because that is the version of the IDE that I have. There is a special grouping called a Monolith that includes several executables, shared libraries, and the kernel. These monoliths have their own set of compile options. I'm not sure how CMake would be able to create these. Also, there are some internal macros that point to the compiler's target BSP and OS that are currently populated via CMake variables: GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME. Depending on the semantics, these may belong in Modules/Platform/os.cmake for some os name of the target platform. We'll need a better understanding of their role to say for sure though. See CMAKE_OSX_SYSROOT in Darwin*.cmake for example. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
On Fri, Oct 03, 2014 at 20:00:00 +0200, Sylvain Joubert wrote: Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) It should be possible to set a property on the target(s) when they are created. Though…looking at the docs, it seems that there's no generic JOB_POOL property for custom targets. When that property is implemented, setting 'console' for these targets for Ninja should be simple enough. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer e...@sf-mail.de wrote: Brad King wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- If it's not available then it should just error out. Aleix PS: I'm alive, working on this, when I get some free time -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
