Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree
On 17/07/14 16:33, Brad King wrote: +# .. command:: configure_package_config_file +# +# Create a config file for a project:: The definition of the command should be in an indented block so that reST knows it is part of the explicit markup block. I indented the whole command block, can you please have a look if that's what you meant? Or is it just the brief description of the command that should be indented? Thanks. Daniele -- 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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
Daniele E. Domenichelli wrote: You can generate valid config files, but in the build tree the relative paths will always be calculated compared to CMAKE_INSTALL_PREFIX, and this does not make sense, and also generates config files with very long lists of ../../../ and difficult to read. Can you give a more-concrete example of what the problem is? Is this relating to a missing target property somehow? Which paths do you need to specify? 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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: I indented the whole command block, can you please have a look if that's what you meant? Or is it just the brief description of the command that should be indented? I think just the signature summary is enough. Section headers can be used if we need a higher-level organization. Also please review the style guidelines: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style In particular, self-references should be plain inline literals: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style-referencing-cmake-domain-objects 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 3.0 COMPILE_DEFINITIONS_CONFIG Documentation
With CMP0043 the COMPILE_DEFINITIONS_Config properties are ignored. This currently doesn't seem to be reflected in the documentation of the properties themselves. Should the documentation for those properties be deleted (I think I would personally prefer that) or extended to show that they may not have any effect when requiring 3.0 (the policy is set to NEW)? Nils -- 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] CMake 3.0 COMPILE_DEFINITIONS_CONFIG Documentation
On 07/21/2014 10:38 AM, Nils Gladitz wrote: Should the documentation for those properties be deleted (I think I would personally prefer that) or extended to show that they may not have any effect when requiring 3.0 (the policy is set to NEW)? The latter, please. See the intro paragraph in export_library_dependencies for example: Help/command/export_library_dependencies.rst 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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
On 21/07/14 14:23, Stephen Kelly wrote:
Can you give a more-concrete example of what the problem is?
I have a project that is similar to this small example:
--- CMakeLists.txt
cmake_minimum_required(VERSION 2.8.12)
project(FOO NONE)
set(FOO_VERSION 0.0.1)
include(${CMAKE_CURRENT_LIST_DIR}/CMakePackageConfigHelpers.cmake)
set(FOO_INSTALL_CMAKE_DIR share/FOO/cmake)
set(FOO_BUILD_ABSOLUTE_DIR ${CMAKE_BINARY_DIR}/share/FOO/absolute)
set(FOO_INSTALL_ABSOLUTE_DIR ${CMAKE_INSTALL_PREFIX}/share/FOO/absolute)
set(FOO_BUILD_RELATIVE_DIR share/FOO/relative)
set(FOO_INSTALL_RELATIVE_DIR share/FOO/relative)
#- BUILD TREE
set(FOO_ABSOLUTE_DIR ${FOO_BUILD_ABSOLUTE_DIR})
set(FOO_RELATIVE_DIR ${FOO_BUILD_RELATIVE_DIR})
# FOOConfig.cmake (build tree)
configure_package_config_file(FOOConfig.cmake.in FOOConfig.cmake
INSTALL_DESTINATION ${CMAKE_BINARY_DIR}
PATH_VARS FOO_ABSOLUTE_DIR
FOO_RELATIVE_DIR
NO_CHECK_REQUIRED_COMPONENTS_MACRO
BUILD_TREE)
#- INSTALLED
set(FOO_ABSOLUTE_DIR ${FOO_INSTALL_ABSOLUTE_DIR})
set(FOO_RELATIVE_DIR ${FOO_INSTALL_RELATIVE_DIR})
# FOOConfig.cmake (installed)
configure_package_config_file(FOOConfig.cmake.in FOOConfigInstall.cmake
INSTALL_DESTINATION ${FOO_INSTALL_CMAKE_DIR}
PATH_VARS FOO_ABSOLUTE_DIR
FOO_RELATIVE_DIR
NO_CHECK_REQUIRED_COMPONENTS_MACRO)
install(FILES
${CMAKE_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/FOOConfigInstall.cmake
DESTINATION ${FOO_INSTALL_CMAKE_DIR}
RENAME FOOConfig.cmake)
--- FOOConfig.cmake.in
set(FOO_VERSION @FOO_VERSION@)
@PACKAGE_INIT@
set_and_check(FOO_ABSOLUTE_DIR @PACKAGE_FOO_ABSOLUTE_DIR@)
set_and_check(FOO_RELATIVE_DIR @PACKAGE_FOO_RELATIVE_DIR@)
The project is supposed to work both from build tree (using
export(TARGETS)) and from the install tree (using install(EXPORT)).
The file FOOConfigInstall.cmake is perfect and can be relocated as
expected.
The file FOOConfig.cmake for the build tree contains
---
[...]
get_filename_component(PACKAGE_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../usr/local ABSOLUTE)
[...]
set_and_check(FOO_ABSOLUTE_DIR absolute path to build
directory/share/FOO/absolute)
set_and_check(FOO_RELATIVE_DIR ${PACKAGE_PREFIX_DIR}/share/FOO/relative)
---
in PACKAGE_PREFIX_DIR, obviously, the length list of /.. depends on
the folder where the package is built. /usr/local is the prefix and it
makes no sense in the file for the build directory.
The path passed using a variable containing an _absolute path_ is
_correct_, but it uses the absolute path to the build directory.
The path passed using a variable containing a _relative path_ is _wrong_
and it contains a path relative to the install directory. If the package
was not installed this path is invalid.
This means that all the paths should be passed as absolute paths or the
generated file will be invalid.
With my patch applied and passing BUILD_TREE to the
configure_package_config_file call, the generated file becomes:
---
[...]
get_filename_component(PACKAGE_PREFIX_DIR ${CMAKE_CURRENT_LIST_DIR}/
ABSOLUTE)
[...]
set_and_check(FOO_ABSOLUTE_DIR ${PACKAGE_PREFIX_DIR}/share/FOO/absolute)
set_and_check(FOO_RELATIVE_DIR ${PACKAGE_PREFIX_DIR}/share/FOO/relative)
---
This removes all the absolute paths from the file (This is not
necessary for using the package in the build tree, since I believe
that it's not going to be relocated, but I still think it is a good
thing), and very important, it allows you to pass relative paths
as PATH_VARS and get the same behaviour in both cases.
Cheers,
Daniele
--
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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
On 21/07/14 16:17, Brad King wrote: On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: I indented the whole command block, can you please have a look if that's what you meant? Or is it just the brief description of the command that should be indented? I think just the signature summary is enough. Section headers can be used if we need a higher-level organization. Done. Also please review the style guidelines: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style In particular, self-references should be plain inline literals: Done. Cheers, Daniele -- 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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
On 07/21/2014 11:38 AM, Daniele E. Domenichelli wrote: Done. Thanks. Please squash in something like the patch below. -Brad diff --git a/Modules/CMakePackageConfigHelpers.cmake b/Modules/CMakePackageConfigHelpers.cmake index 24b5b74..54ceb54 100644 --- a/Modules/CMakePackageConfigHelpers.cmake +++ b/Modules/CMakePackageConfigHelpers.cmake @@ -8,7 +8,8 @@ # Adds the :command:`configure_package_config_file()` and # :command:`write_basic_package_version_file()` commands. # -# +# Generating a Package Configuration File +# ^^^ # # .. command:: configure_package_config_file # @@ -104,10 +105,10 @@ # When using the ``NO_CHECK_REQUIRED_COMPONENTS_MACRO`` option, this macro is # not generated into the ``FooConfig.cmake`` file. # -# For an example see below the documentation for -# :command:`write_basic_package_version_file()`. -# +# See the `Example Generating Package Files`_ below. # +# Generating a Package Version File +# ^ # # .. command:: write_basic_package_version_file # @@ -154,6 +155,8 @@ # :command:`configure_file()` on them yourself, but they can be used as starting # point to create more sophisticted custom ``ConfigVersion.cmake`` files. # +# Example Generating Package Files +# # # Example using both :command:`configure_package_config_file` and # ``write_basic_package_version_file()``: -- 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] [Review Request] Topic CMakePackageConfigHelpers_build_tree
Daniele E. Domenichelli wrote:
On 21/07/14 14:23, Stephen Kelly wrote:
Can you give a more-concrete example of what the problem is?
The project is supposed to work both from build tree (using
export(TARGETS)) and from the install tree (using install(EXPORT)).
Your example is too abstract. What is the meaning of the paths?
What is the problem which can be solved only with CMakePackageConfigHelpers
and can't be solved (currently) another way? Is there a first-class feature
CMake could learn to make this stuff easier?
Here is why I am asking:
The documentation at
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
does not use CMakePackageConfigHelpers because for 'modern' packages, paths
such as include directories are encoded into imported targets. Then the
complete FooConfig.cmake file is:
include(CMakeFindDependencyMacro)
find_dependency(Stats 2.6.4)
include(${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake)
and it works as both a build-location package and an install-location
package, without using CMakePackageConfigHelpers.
That is assuming the ClimbingStatsMacros.cmake can be generated in or copied
to the build location. That is an easy assumption to make, because it is
easy to do such generation or copying.
So, I am trying to find out:
When using 'modern cmake', is there a remaining need for
CMakePackageConfigHelpers?
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] LZMA support
On 07/20/2014 05:22 AM, Daniel Pfeifer wrote: * add the liblzma source from XZ Utils * make it compile with CMake (by adding CMakeLists.txt etc.) * make it compile in VC6 (by porting the source from C99 to C90) * make cmlibarchive use cmliblzma (using cm_lzma.h) * add cpack generators for .7z and .tar.xz Wonderful, thanks! I restructured the topic a bit to make it easier to update the liblzma version in the future. I also added references to the issue numbers to the commit messages. I've temporarily published an 'add-liblzma' branch to our topic stage at http://cmake.org/stage/cmake.git. After some further manual testing I will merge it 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
[CMake] CMAKE changing Visual Studio Settings
I've been using CMAKE recently on Linux and Windows and I really like it. Its a great way of spinning up a project and organizing your builds. There are just a few things that are bugging me and I'm hoping to get help here. Visual Studio Settings Every time CMAKE generates a project it will be a fresh solution and will not maintain any of the settings you applied to the Visual Studio project. I know that many things such as CMAKE_CXX_FLAGS, etc can change the properties. But what if I want to change settings such as Suppress Startup Banner, Environment, Enabling Microsoft Symbol Server, Enabling Native Code Debugging. How do I force CMAKE to set the options I want for fields like these? Combining Debug/Release/Etc into one solution It seems that with CMAKE you have to do separate generations for Debug/Release/etc. But in typical manually created Visual Studio projects you can combine the profiles and just change a project setting to get your new settings. Is it possible to generate a single solution file from CMAKE? Thanks! -- 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
Re: [CMake] CMAKE changing Visual Studio Settings
On 07/21/2014 08:05 AM, Joseph Rosensweig wrote: Visual Studio Settings Every time CMAKE generates a project it will be a fresh solution and will not maintain any of the settings you applied to the Visual Studio project. I know that many things such as CMAKE_CXX_FLAGS, etc can change the properties. But what if I want to change settings such as Suppress Startup Banner, Environment, Enabling Microsoft Symbol Server, Enabling Native Code Debugging. How do I force CMAKE to set the options I want for fields like these? Some options are stored in the project files and can be derived from compiler options (e.g. Suppress Startup Banner is derived from /NOLOGO). These would get overwritten on generation. Other options (like e.g. the Debugging Environment) are stored in .user files which are neither generated nor overwritten by CMake. Combining Debug/Release/Etc into one solution It seems that with CMAKE you have to do separate generations for Debug/Release/etc. CMake has multi-configuration and single-configuration generators. The Visual Studio generators are multi-configuration which means they generate a single solution which contains all configurations (per default Debug, Release, RelWithDebInfo and MinSizeRel). Nils -- 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
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in your
static and dynamic CMakeLists.txt to include the flags you wish in the
following way:
set(CMAKE_EXE_LINKER_FLAGS -whole-archive)
If you set this variable to include more custom linker flags which you want
to preserve across libraries, then you should set it in the following way
to preserve its old value:
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)
If you want to edit linker flags for a shared library or a module target
you can use these cmake variables (set them before add_library):
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
Be aware that variables have CMakeLists.txt file scope, so if you set
different values in one CMakeLists.txt then they might get overwritten or
appended (depending on the way you edit the variable).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various
project specific library folders which each build a static library. The
testbench folder is the one that builds both the executable and the dynamic
library. When building the dynamic library I need to use the linker
options -whole-archive and -no-whole-archive to force my static project
libraries to be included into the dynamic library. The problem is how to
insert the -whole-archive and -no-whole-archive options so that they select
the correct set of libraries. Currently in the testbench CMakeLists.txt
file I have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt -lm -lrt
The problem is that the 6 external_mtx libraries should have been
included inside the -whole-archive section. These libraries are specified
in the mtx_wrapper folder with a target_link_libraries(mtx_wrapper
${METASIM_LIBRARIES}) command. I have managed to wrap the direct library
dependencies inside the -whole-archive but I need to ensure that any
sub-dependencies are included as well (and any dependencies they might have
recursively). Any system dynamic libaries (-ldl -lm -lrt etc.) must appear
after the -no-whole-archive option otherwise the link fails. The
mtx_wrapper library can be built in two ways and only one of them will add
the extra METASIM libraries as a dependency, the other way fakes that code
internally. Adding the METASIM libraries via target_link_libraries()
inside the mtx_wrapper CMakeLists.txt
[CMake] Source List Compilation Depending on Configuration
Hi! if i want to add sources to list of compilation i can rely on CMAKE_BUILD_TYPE. E.g if i want to add a source file only for release, i append it to list of source files only then. BUT: how can i do this for multi configuration like vs? So i want to add it to the sources, so that it appears in vs, but only want to compile it in release build? Is there an easy way to handle this? Thanks, Joerg Mannheim HRB 504702 Geschäftsführer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH) Dipl.-Inf. (FH) Jens Heyen This e-mail may contain confidential and/or legally protected information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you! -- 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
Re: [CMake] Source List Compilation Depending on Configuration
On 07/21/2014 11:46 AM, Jörg Kreuzberger wrote: Hi! if i want to add sources to list of compilation i can rely on CMAKE_BUILD_TYPE. E.g if i want to add a source file only for release, i append it to list of source files only then. BUT: how can i do this for multi configuration like vs? So i want to add it to the sources, so that it appears in vs, but only want to compile it in release build? Is there an easy way to handle this? I don't think CMake supports configuration specific source files (I assume this might not be supported by all target build systems?). It should be possible to use the preprocessor (with configuration specific defines through the COMPILE_DEFINITIONS_CONFIG property) to work around it. E.g. either guard the source file's content itself with #ifdef CONFIG_SPECIFIC_DEFINE source file content #endif or add a wrapper source file that does something like #ifdef CONFIG_SPECIFIC_DEFINE #include config1.cpp #endif or even #ifdef CONFIG_SPECIFIC_DEFINE #include config1.cpp #else #include config2.cpp #endif Nils -- 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
Re: [CMake] Source List Compilation Depending on Configuration
Jörg Kreuzberger wrote: Is there an easy way to handle this? Try a nightly build: http://www.cmake.org/files/dev/?C=M;O=D And a generator expression: http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html add_library(mylib bar.cpp $$CONFIG:Debug:foo.cpp ) Testing the value of CMAKE_BUILD_TYPE is not the right/portable thing to do for exactly the reason you discovered. 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
Re: [CMake] Source List Compilation Depending on Configuration
Hm, following your suggestion i replace lines
if( ${CMAKE_BUILD_TYPE} STREQUAL Release)
add_definitions( -DNDEBUG )
endif()
with
set_directory_properties( PROPERTIES COMPILE_DEFINITIONS_RELEASE
${COMPILE_DEFINITIONS_RELEASE};NDEBUG )
it didnt worked. ( inspecting e.q. flags.make and compilation )
if i set COMPILE_DEFINITIONS (without config) it worked. This is the point i
stuct like above again.
-Ursprüngliche Nachricht-
Von:Nils Gladitz nilsglad...@gmail.com
Gesendet: Mo 21.07.2014 12:13
Betreff:Re: [CMake] Source List Compilation Depending on Configuration
An: Jörg Kreuzberger j.kreuzber...@procitec.de; cmake@cmake.org;
On 07/21/2014 11:46 AM, Jörg Kreuzberger wrote:
Hi!
if i want to add sources to list of compilation i can rely on
CMAKE_BUILD_TYPE.
E.g if i want to add a source file only for release, i append it to list of
source files only then.
BUT: how can i do this for multi configuration like vs?
So i want to add it to the sources, so that it appears in vs, but only want
to compile it in release build?
Is there an easy way to handle this?
I don't think CMake supports configuration specific source files (I
assume this might not be supported by all target build systems?).
It should be possible to use the preprocessor (with configuration
specific defines through the COMPILE_DEFINITIONS_CONFIG property) to
work around it.
E.g. either guard the source file's content itself with
#ifdef CONFIG_SPECIFIC_DEFINE
source file content
#endif
or add a wrapper source file that does something like
#ifdef CONFIG_SPECIFIC_DEFINE
#include config1.cpp
#endif
or even
#ifdef CONFIG_SPECIFIC_DEFINE
#include config1.cpp
#else
#include config2.cpp
#endif
Nils
Mannheim HRB 504702
Geschäftsführer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH)
Dipl.-Inf. (FH) Jens Heyen
This e-mail may contain confidential and/or legally protected information. If
you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Thank you!
--
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
Re: [CMake] Source List Compilation Depending on Configuration
On 07/21/2014 02:29 PM, Jörg Kreuzberger wrote:
Hm, following your suggestion i replace lines
if( ${CMAKE_BUILD_TYPE} STREQUAL Release)
add_definitions( -DNDEBUG )
endif()
with
set_directory_properties( PROPERTIES COMPILE_DEFINITIONS_RELEASE
${COMPILE_DEFINITIONS_RELEASE};NDEBUG )
${COMPILE_DEFINITIONS_RELEASE} does not expand the property but you
could use set_property() with the APPEND flag for that.
NDEBUG is set by default for MinSizeRel, Release and RelWithDebInfo so
you should have found it in the Release flags even without using the
property (unless you override the default flags).
With
set_directory_properties(PROPERTIES COMPILE_DEFINITIONS_RELEASE FOOBAR)
I get
./CMakeFiles/foo.dir/flags.make:CXX_DEFINES = -DFOOBAR
When configuring a Release build with the Makefiles generator.
Nils
--
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
Re: [CMake] Source List Compilation Depending on Configuration
1) i reset it with
set( CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} )
set( CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE_INIT} )
set( CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG_INIT} )
and then append my own custom compiler definitions. -DNDEBUG appears in
flags.make, only in CXX_FLAGS, but not in CXX_DEFINES!
and this is the issue i had with it: as long it appears only in CXX_FLAGS, it
works for the code compilation but it does not work for qt4_wrapp_cpp (missing
defines for moc).
2) the point i want to change global compiler properties is in my toplevel
CMakeLists.txt,
there i do
include( cmake/GlobalCompilerSettings.cmake)
3) following your example, it does not work for COMPILE_DEFINITIONS_RELEASE,
but does work for COMPILE_DEFINITIONS.
(works means it appears in CXX_DEFINES)
using release cmake 3.0.0 version. Platform is ubuntu linux (makefile generator)
-Ursprüngliche Nachricht-
Von:Nils Gladitz nilsglad...@gmail.com
Gesendet: Mo 21.07.2014 14:45
Betreff:Re: AW: [CMake] Source List Compilation Depending on
Configuration
An: Jörg Kreuzberger j.kreuzber...@procitec.de;
CC: cmake@cmake.org;
On 07/21/2014 02:29 PM, Jörg Kreuzberger wrote:
Hm, following your suggestion i replace lines
if( ${CMAKE_BUILD_TYPE} STREQUAL Release)
add_definitions( -DNDEBUG )
endif()
with
set_directory_properties( PROPERTIES COMPILE_DEFINITIONS_RELEASE
${COMPILE_DEFINITIONS_RELEASE};NDEBUG )
${COMPILE_DEFINITIONS_RELEASE} does not expand the property but you
could use set_property() with the APPEND flag for that.
NDEBUG is set by default for MinSizeRel, Release and RelWithDebInfo so
you should have found it in the Release flags even without using the
property (unless you override the default flags).
With
set_directory_properties(PROPERTIES COMPILE_DEFINITIONS_RELEASE FOOBAR)
I get
./CMakeFiles/foo.dir/flags.make:CXX_DEFINES = -DFOOBAR
When configuring a Release build with the Makefiles generator.
Nils
Mannheim HRB 504702
Geschäftsführer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH)
Dipl.-Inf. (FH) Jens Heyen
This e-mail may contain confidential and/or legally protected information. If
you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Thank you!
--
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
Re: [CMake] Source List Compilation Depending on Configuration
On 07/21/2014 03:19 PM, Jörg Kreuzberger wrote:
1) i reset it with
set( CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} )
set( CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE_INIT} )
set( CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG_INIT} )
and then append my own custom compiler definitions. -DNDEBUG appears in
flags.make, only in CXX_FLAGS, but not in CXX_DEFINES!
and this is the issue i had with it: as long it appears only in CXX_FLAGS, it
works for the code compilation but it does not work for qt4_wrapp_cpp (missing
defines for moc).
2) the point i want to change global compiler properties is in my toplevel
CMakeLists.txt,
there i do
include( cmake/GlobalCompilerSettings.cmake)
3) following your example, it does not work for COMPILE_DEFINITIONS_RELEASE,
but does work for COMPILE_DEFINITIONS.
(works means it appears in CXX_DEFINES)
using release cmake 3.0.0 version. Platform is ubuntu linux (makefile generator)
I forgot that COMPILE_DEFINITIONS_CONFIG were deprecated.
When you require 3.0 the property is ignored (Policy CMP0043).
$$CONFIG:Release:NDEBUG in COMPILE_DEFINITIONS should work.
Nils
--
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
Re: [CMake] Source List Compilation Depending on Configuration
ok, then it worked.
i got no warning on the policies, maybe i would have then detected it further.
Can i enable them globally?
-Ursprüngliche Nachricht-
Von:Nils Gladitz nilsglad...@gmail.com
Gesendet: Mo 21.07.2014 15:36
Betreff:Re: AW: [CMake] Source List Compilation Depending on
Configuration
An: Jörg Kreuzberger j.kreuzber...@procitec.de;
CC: cmake@cmake.org;
On 07/21/2014 03:19 PM, Jörg Kreuzberger wrote:
1) i reset it with
set( CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} )
set( CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE_INIT} )
set( CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG_INIT} )
and then append my own custom compiler definitions. -DNDEBUG appears in
flags.make, only in CXX_FLAGS, but not in CXX_DEFINES!
and this is the issue i had with it: as long it appears only in CXX_FLAGS,
it
works for the code compilation but it does not work for qt4_wrapp_cpp
(missing
defines for moc).
2) the point i want to change global compiler properties is in my toplevel
CMakeLists.txt,
there i do
include( cmake/GlobalCompilerSettings.cmake)
3) following your example, it does not work for
COMPILE_DEFINITIONS_RELEASE,
but does work for COMPILE_DEFINITIONS.
(works means it appears in CXX_DEFINES)
using release cmake 3.0.0 version. Platform is ubuntu linux (makefile
generator)
I forgot that COMPILE_DEFINITIONS_CONFIG were deprecated.
When you require 3.0 the property is ignored (Policy CMP0043).
$$CONFIG:Release:NDEBUG in COMPILE_DEFINITIONS should work.
Nils
Mannheim HRB 504702
Geschäftsführer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH)
Dipl.-Inf. (FH) Jens Heyen
This e-mail may contain confidential and/or legally protected information. If
you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Thank you!
--
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
Re: [CMake] Source List Compilation Depending on Configuration
On 07/21/2014 04:01 PM, Jörg Kreuzberger wrote: ok, then it worked. i got no warning on the policies, maybe i would have then detected it further. Can i enable them globally? With cmake_minimum_required(VERSION 3.0) the new behaviour is used for the policy which is to ignore the property without warning. I think to get a warning you would have had to require an older version while using CMake 3.0 which I guess only makes this detectable when migrating an existing project from an older version after already having upgraded to 3.0. Nils -- 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
[CMake] COMPILE_DEFINITONS Generator Expressions and MOC
Hi! After much help from Nils from the list i am able to use GENERATOR expressions in my compile definitions. But i end up in the moc'ing step for my qt4 files. The cmake macros QT4_WRAP_CPP generates a moc command file called moc_...cxx_parameters, that contains the generator expression values -D$$CONFIG:Release:NDEBUG at this point cmake should have already resolved them to -DNDEBUG if i build a release? or then are the generator expressions for moc resolved? Mannheim HRB 504702 Geschäftsführer: Dipl.-Ing. (FH) Michael Brenk (Vorsitzender), Dipl.-Ing. (FH) Dipl.-Inf. (FH) Jens Heyen This e-mail may contain confidential and/or legally protected information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you! -- 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
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
The problem is that I need to add both -whole-archive and -no-whole-archive
options. And I need to control exactly where they occur so that only my
libraries occur inside the whole archive section. I'd be happy to be
proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS will give me
that level of control.
--
Glenn
On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in your
static and dynamic CMakeLists.txt to include the flags you wish in the
following way:
set(CMAKE_EXE_LINKER_FLAGS -whole-archive)
If you set this variable to include more custom linker flags which you
want to preserve across libraries, then you should set it in the following
way to preserve its old value:
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)
If you want to edit linker flags for a shared library or a module target
you can use these cmake variables (set them before add_library):
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
Be aware that variables have CMakeLists.txt file scope, so if you set
different values in one CMakeLists.txt then they might get overwritten or
appended (depending on the way you edit the variable).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various
project specific library folders which each build a static library. The
testbench folder is the one that builds both the executable and the dynamic
library. When building the dynamic library I need to use the linker
options -whole-archive and -no-whole-archive to force my static project
libraries to be included into the dynamic library. The problem is how to
insert the -whole-archive and -no-whole-archive options so that they select
the correct set of libraries. Currently in the testbench CMakeLists.txt
file I have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt -lm -lrt
The problem is that the 6 external_mtx libraries should have been
included inside the -whole-archive section. These libraries are specified
in the mtx_wrapper folder with a target_link_libraries(mtx_wrapper
${METASIM_LIBRARIES}) command. I have managed to wrap the direct library
dependencies inside the -whole-archive but I need to ensure that any
sub-dependencies are included as well (and any
Re: [CMake] find_package and INTERFACE targets in 3.0
Hendrick! That's exactly what I'm trying to do. Do you have an example
of the declaration of the dll import target setup you could share? That
would be immensely helpful.
Thanks
Walter
On 7/19/2014 4:01 AM, Hendrik Sattler wrote:
Hi,
for DLLs, the .lib part has it's own property IMPORTED_IMPLIB.
This is already the case for older versions of CMake but at least the Qt4 find
module makes no use of it.
In our own project, we use global imported targets with dll and import lib set
(and other properties like includes) and use it on Windows to copy the dlls to
the target location with a generator expression and post-build.
I guess on Windows, BundleUtilities could also be simplified if that was done
consistently.
On all platforms it's rather complicated to find out if a .lib/.so is static or
shared. IMHO this should be solved by a function that module writers can use,
either on a CMake module or integrated.
So currently, you can either guess or use UNKNOWN.
Regards,
HS
On 19. Juli 2014 05:13:13 MESZ, Walter Gray chrysal...@gmail.com wrote:
Thanks Nils!
The examples in the git repo are particularly helpful. It seems that
in
all of the examples, the library type is being set to UNKNOWN. Is
there
a reason for this? It seems that STATIC would be more suitable for most
of those, though the wording in the docs for IMPORTED_LOCATION [1]
makes
it seem like maybe for STATIC's it's just the directory and not the
actual .lib file. I notice cmake doesn't seem to have any way to track
DLLs or dylibs. Is there some recommended way of dealing with
importing
shared libraries? The QT4 module was my best bet but it doesn't seem to
touch the .dlls at all. I tried writing some of my own for shared
libraries like SDL2, I noticed that add_libraries(SHARED IMPORTED) does
not seem to work as I expected. An example for Windows(from memory,
I'll update with the real run outputs on Monday when I'm back at the
office):
add_library(SDL2::SDL2 SHARED IMPORTED GLOBAL)
set_target_properties(SDL2::SDL2 PROPERTIES
INTERFACE_LINK_LIBRARIES
${SDL_ROOT_DIR}/lib/SDL2main.lib;${SDL_ROOT_DIR}/lib/SDL2.lib
INTERFACE_INCLUDE_DIRECTORIES ${SDL_ROOT_DIR}/include
IMPORTED_LOCATION ${SDL_ROOT_DIR}/lib/SDL2.dll
)
According to the docs for IMPORTED_LOCATION [1], for shared libraries
on
DLL platforms, it should point to the DLL part of the library. When I
add the SDL2::SDL2 to my main target, it compiles generates but when
I
run the resulting visual studio project it results in link errors with
(and this is the part I'm not sure about - again, more concrete detail
on Monday) SDL2-NOTFOUND.o and SDL2::SDL2
I suspect I'm using INTERFACE_LINK_LIBRARIES in not quite the right
way,
but those *are* the public .lib files. When I get back on Monday I'll
try a few different approaches based on what I saw in some of the
modules, namely making sub-libraries with UNKNOWN and IMPORTED_LOCATION
set for all the actual .lib files, and just directly setting
LINK_LIBRARIES
[1]
http://www.cmake.org/cmake/help/git-master/prop_tgt/IMPORTED_LOCATION.html
On 7/18/2014 5:23 AM, Nils Gladitz wrote:
On 07/18/2014 05:00 AM, Walter Gray wrote:
Hi list!
I'm a big fan of the new INTERFACE targets target usage
requirements,
but none of the provided Findpackage.cmake files seem to take
advantage of the new paradigm. Checking the wiki, the old
Findpackage.cmake seem to be deprecated, with most of the
information
on authoring new packages assuming that you are the developer of the
module, not the consumer. What is the recommended way to deal with
packages that don't provide these config files? I'll happily write
my
own Findpackage.cmake files, however that approach seems
deprecated
and I haven't found any good examples of find modules that define
IMPORT
or INTERFACE targets instead of the older method of setting a bunch
of
package_xxx variables.
There are a few modules that use imported targets in 3.0 and a few
more were updated in master.
I see e.g. FindGLUT, FindQt4, FindGTK2, FindZLIB, FindOpenGL and
FindGLEW making use of imported targets in master[1].
[2] documents how to write find modules and includes an example with
IMPORTED targets.
Nils
[1]
http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules;h=5d17682cb231f119b677ce67d804852d3be6d46f;hb=HEAD
[2]
http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules
--
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:
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
Well try it and see if it works. If you set this variable in a specific
CMakeLists file, it will affect the specific add_library (or
add_executable) that is in that CMakeLists file. With this way you can
control which libraries/executables will be linked with these flags, and
this is the level of control you have.
Cheers!
Angeliki
On Mon, Jul 21, 2014 at 7:05 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
The problem is that I need to add both -whole-archive and
-no-whole-archive options. And I need to control exactly where they occur
so that only my libraries occur inside the whole archive section. I'd be
happy to be proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS
will give me that level of control.
--
Glenn
On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in your
static and dynamic CMakeLists.txt to include the flags you wish in the
following way:
set(CMAKE_EXE_LINKER_FLAGS -whole-archive)
If you set this variable to include more custom linker flags which you
want to preserve across libraries, then you should set it in the following
way to preserve its old value:
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)
If you want to edit linker flags for a shared library or a module target
you can use these cmake variables (set them before add_library):
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
Be aware that variables have CMakeLists.txt file scope, so if you set
different values in one CMakeLists.txt then they might get overwritten or
appended (depending on the way you edit the variable).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various
project specific library folders which each build a static library. The
testbench folder is the one that builds both the executable and the dynamic
library. When building the dynamic library I need to use the linker
options -whole-archive and -no-whole-archive to force my static project
libraries to be included into the dynamic library. The problem is how to
insert the -whole-archive and -no-whole-archive options so that they select
the correct set of libraries. Currently in the testbench CMakeLists.txt
file I have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt
[CMake] My Documents folder
Hi, Is it possible to (easily) install a file, say Readme.txt, into a users My Documents folder, using CMake/CPack? I can't find information about such.. :( -tk -- View this message in context: http://cmake.3232098.n2.nabble.com/My-Documents-folder-tp7587946.html Sent from the CMake mailing list archive at Nabble.com. -- 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
Re: [CMake] how to add new source files in already build cmake project from inside eclipse cdt?
On Monday, July 21, 2014 08:40:11 Payal Prajapati wrote: hello All, Two things to say: 1)I read all conversion regarding this topic..but can any one explain me the whole procedure? 2)I am working on orfeo toolbox which i imported in eclipse.It works fine upto make target-build step. but when i do make target-build-install and then finish it gives me an error(highlighted with red mark on projectname). can any one explain which steps are required for building project after importing it in eclipse? Any help would be appreciable. you just have to add it to your CMakeLists.txt. Upon the next build, cmake will run again and regenerate the makefiles and Eclispe project files. You may need to manually refresh the project in Eclipse. Alex -- 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
Re: [CMake] Considering contributing a FindPyQt.cmake module
Scott Kitterman wrote: Given the above, I thought it would make sense to provide a new FindPyQt.cmake that would replace (and be backward compatible with) FindPyQt4.cmake that would work for both the new and old PyQt4 configure and with PyQt5 and have it be actually in CMake so that there would not be multiple copies running around. Did you consider generating config-file packages containing IMPORTED targets and shipping them with PyQt5 instead? http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html That removes any need for you to maintain anything in the CMake tree. Qt5 generates such files with qmake, and LLVM does similar with its Makefile buildsystem. 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
Re: [CMake] CMAKE changing Visual Studio Settings
On Sun, Jul 20, 2014 at 11:49 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 07/21/2014 08:05 AM, Joseph Rosensweig wrote: Visual Studio Settings Every time CMAKE generates a project it will be a fresh solution and will not maintain any of the settings you applied to the Visual Studio project. I know that many things such as CMAKE_CXX_FLAGS, etc can change the properties. But what if I want to change settings such as Suppress Startup Banner, Environment, Enabling Microsoft Symbol Server, Enabling Native Code Debugging. How do I force CMAKE to set the options I want for fields like these? Some options are stored in the project files and can be derived from compiler options (e.g. Suppress Startup Banner is derived from /NOLOGO). These would get overwritten on generation. So CMAKE can't control the options int he *.user files I guess :-\? Would a potential workaround be to find a command line tool that can edit these and run it as a post-build script? Other options (like e.g. the Debugging Environment) are stored in .user files which are neither generated nor overwritten by CMake. Combining Debug/Release/Etc into one solution It seems that with CMAKE you have to do separate generations for Debug/Release/etc. CMake has multi-configuration and single-configuration generators. The Visual Studio generators are multi-configuration which means they generate a single solution which contains all configurations (per default Debug, Release, RelWithDebInfo and MinSizeRel). I see that it makes these profiles in my Visual Studio project. But in my CMAKE I have places where I do things like if(CMAKE_BUILD_TYPE STREQUAL Debug) then do this else do that. i.e. my CXX Flags will change based on the CMAKE_BUILD_TYPE. However I don't see these getting reflected in my Visual Studio configurations. What am I missing? Nils -- 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
Re: [CMake] CMAKE changing Visual Studio Settings
So CMAKE can't control the options int he *.user files I guess :-\? Would a potential workaround be to find a command line tool that can edit these and run it as a post-build script? CMake gives you the functionality needed to edit these via your own script. I mean reading and writing files replacing text. John -- 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
Re: [CMake] My Documents folder
On 07/21/2014 09:07 PM, Totte Karlsson wrote: Hi, Is it possible to (easily) install a file, say Readme.txt, into a users My Documents folder, using CMake/CPack? I can't find information about such.. :( I'd consider having the installed application set these up when run since specifically for system wide installations: - the user that performs the install may not be the user that runs the application - there may be multiple users - the potential user(s) are created after the installation Nils -- 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
Re: [CMake] My Documents folder
Hi Nils, Thanks for your reply. The installed application is a python module and it should not ever perform any file install/copy operations. It is an absolute requirement that the installer are able to install files into the users MyDoc folder (or even other common system folders, sucha as AllUsers etc.). I cannot find out how to do this with CPack. Seem I will have to create a nsis script to do so? Seem quite complicated :( tk -- View this message in context: http://cmake.3232098.n2.nabble.com/My-Documents-folder-tp7587946p7587952.html Sent from the CMake mailing list archive at Nabble.com. -- 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
[CMake] How to set Look for CMakeDetermineLang.cmake here
I am attempting to build an easy-to-use build system for an embedded system. This chip uses .dat, .spin, .cogc, and .ecogc files along with .S, .c, and .cpp. I've added the necessary language files to my project path which will enable cogc (I'll get to the other file types eventually) and they work great, but it requires manually linking or copying the files out of the project directory and into CMake's installation path. Is there some way to tell CMake that it should look for these files in a custom path? Thanks, David -- 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
Re: [CMake] Considering contributing a FindPyQt.cmake module
On Monday, July 21, 2014 22:41:32 Stephen Kelly wrote: Scott Kitterman wrote: Given the above, I thought it would make sense to provide a new FindPyQt.cmake that would replace (and be backward compatible with) FindPyQt4.cmake that would work for both the new and old PyQt4 configure and with PyQt5 and have it be actually in CMake so that there would not be multiple copies running around. Did you consider generating config-file packages containing IMPORTED targets and shipping them with PyQt5 instead? http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html That removes any need for you to maintain anything in the CMake tree. Qt5 generates such files with qmake, and LLVM does similar with its Makefile buildsystem. I had not considered that. I'm not upstream for PyQt, so I can't say for sure, but I can ask if patches for that would be accepted. Thanks, Scott K -- 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
[Cmake-commits] CMake branch, master, updated. v3.0.0-1462-gb86f0e4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via b86f0e445b1d7f9e58c8d2d9f14c7501e734057d (commit) via 6f3e094e9f0017b63e138e001c86e467c8f9b7c9 (commit) via d4d1b7f7d1d6592f12a6692dfb8068aa495bd454 (commit) from 8e018ae44e80425ee77db675fb452b9e0eb9730c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b86f0e445b1d7f9e58c8d2d9f14c7501e734057d commit b86f0e445b1d7f9e58c8d2d9f14c7501e734057d Merge: 8e018ae 6f3e094 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jul 21 10:36:00 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 10:36:00 2014 -0400 Merge topic 'update-kwsys' 6f3e094e Merge branch 'upstream-kwsys' into update-kwsys d4d1b7f7 KWSys 2014-07-18 (65b36ede) --- Summary of changes: Source/kwsys/SystemInformation.cxx |5 - Source/kwsys/Terminal.c|6 +++--- Source/kwsys/testProcess.c | 15 +++ 3 files changed, 22 insertions(+), 4 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-1464-gc86b99c
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via c86b99c351d313f3e45ee895a6166d55e86b245c (commit)
via 3151024d241c581463d20bf0ce3d1060bdd22de4 (commit)
from b86f0e445b1d7f9e58c8d2d9f14c7501e734057d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c86b99c351d313f3e45ee895a6166d55e86b245c
commit c86b99c351d313f3e45ee895a6166d55e86b245c
Merge: b86f0e4 3151024
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 10:36:07 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 21 10:36:07 2014 -0400
Merge topic 'fix-QCC-compile-flags'
3151024d QNX: Add missing flags for configurations and artifact creation.
---
Summary of changes:
Modules/Compiler/QCC-C.cmake |2 ++
Modules/Compiler/QCC-CXX.cmake | 12 +++
.../QCC.cmake} | 12 +++
Modules/Platform/QNX-QCC-C.cmake |4
Modules/Platform/QNX-QCC-CXX.cmake |4
Modules/Platform/QNX.cmake | 22 +++-
6 files changed, 25 insertions(+), 31 deletions(-)
create mode 100644 Modules/Compiler/QCC-C.cmake
create mode 100644 Modules/Compiler/QCC-CXX.cmake
copy Modules/{CMakeSystemSpecificInitialize.cmake = Compiler/QCC.cmake} (62%)
delete mode 100644 Modules/Platform/QNX-QCC-C.cmake
delete mode 100644 Modules/Platform/QNX-QCC-CXX.cmake
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-4388-g154cfe3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 154cfe3c03b0c52bdc5ca15054b78567e1d98152 (commit) via c86b99c351d313f3e45ee895a6166d55e86b245c (commit) via b86f0e445b1d7f9e58c8d2d9f14c7501e734057d (commit) via 8e018ae44e80425ee77db675fb452b9e0eb9730c (commit) via 6ae98ee18f6c35b93556a66dc0ce909d84aec18b (commit) via 18a431068105c14e5b4a6d91dacac36b1f9981ef (commit) from 97d24d35216972ee496fa38d855bcdc72a694aaa (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=154cfe3c03b0c52bdc5ca15054b78567e1d98152 commit 154cfe3c03b0c52bdc5ca15054b78567e1d98152 Merge: 97d24d3 c86b99c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jul 21 10:50:15 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jul 21 10:50:15 2014 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-4390-g4ceee50
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4ceee50e1d51f8bea1a6f76ec267712457a39b02 (commit) via cc3248f45231d24061bbc88fa6dd66897162cb3a (commit) from 154cfe3c03b0c52bdc5ca15054b78567e1d98152 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4ceee50e1d51f8bea1a6f76ec267712457a39b02 commit 4ceee50e1d51f8bea1a6f76ec267712457a39b02 Merge: 154cfe3 cc3248f Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jul 21 10:49:55 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 10:49:55 2014 -0400 Merge topic 'backport-kwsys-qnx-fix' into next cc3248f4 KWSys SystemInformation: No SA_RESTART on QNX http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc3248f45231d24061bbc88fa6dd66897162cb3a commit cc3248f45231d24061bbc88fa6dd66897162cb3a Author: Bob E ebob...@gmail.com AuthorDate: Thu Jul 17 06:23:00 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jul 17 09:51:48 2014 -0400 KWSys SystemInformation: No SA_RESTART on QNX QNX not support SA_RESTART signal: /* #define SA_RESTART 0x0040 (not supported yet) */ Use it in SystemInformation only if it is defined. diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx index ec3a133..a03b39c 100644 --- a/Source/kwsys/SystemInformation.cxx +++ b/Source/kwsys/SystemInformation.cxx @@ -3696,7 +3696,10 @@ void SystemInformationImplementation::SetStackTraceOnError(int enable) // install ours struct sigaction sa; sa.sa_sigaction=(SigAction)StacktraceSignalHandler; -sa.sa_flags=SA_SIGINFO|SA_RESTART|SA_RESETHAND; +sa.sa_flags=SA_SIGINFO|SA_RESETHAND; +# ifdef SA_RESTART +sa.sa_flags|=SA_RESTART; +# endif sigemptyset(sa.sa_mask); sigaction(SIGABRT,sa,0); --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-1466-g23ec373
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 23ec3738a0bafd23a9d37fc72e7183e8dc84a4ac (commit) via cc3248f45231d24061bbc88fa6dd66897162cb3a (commit) from c86b99c351d313f3e45ee895a6166d55e86b245c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23ec3738a0bafd23a9d37fc72e7183e8dc84a4ac commit 23ec3738a0bafd23a9d37fc72e7183e8dc84a4ac Merge: c86b99c cc3248f Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jul 21 10:49:59 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 10:49:59 2014 -0400 Merge topic 'backport-kwsys-qnx-fix' cc3248f4 KWSys SystemInformation: No SA_RESTART on QNX --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-4392-g8187de1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 8187de1946953a26308be5b3054fb0ec5ca59766 (commit) via 23ec3738a0bafd23a9d37fc72e7183e8dc84a4ac (commit) from 4ceee50e1d51f8bea1a6f76ec267712457a39b02 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8187de1946953a26308be5b3054fb0ec5ca59766 commit 8187de1946953a26308be5b3054fb0ec5ca59766 Merge: 4ceee50 23ec373 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jul 21 10:51:29 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jul 21 10:51:29 2014 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.0-4396-gfe74f3b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fe74f3b9dc321a3340b9e96646a193469d0be653 (commit)
via c3de083ee5cab903b2925908e9a330a9b27e2ffd (commit)
via e5821c20de537662b62d91d276499dd797963d6e (commit)
via bbea91c7b37bbe41db19c8cadf554af0fd55e4e9 (commit)
from 8187de1946953a26308be5b3054fb0ec5ca59766 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe74f3b9dc321a3340b9e96646a193469d0be653
commit fe74f3b9dc321a3340b9e96646a193469d0be653
Merge: 8187de1 c3de083
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 10:57:18 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 21 10:57:18 2014 -0400
Merge topic 'target-drop-build-setting-cache' into next
c3de083e genex-head-sensitive-conditions
e5821c20 cmTarget: Drop internal cache of build properties
bbea91c7 cmTarget: Drop internal cache of link interface usage requirements
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c3de083ee5cab903b2925908e9a330a9b27e2ffd
commit c3de083ee5cab903b2925908e9a330a9b27e2ffd
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Jul 18 15:36:23 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Jul 18 15:36:23 2014 -0400
genex-head-sensitive-conditions
diff --git a/Source/cmGeneratorExpression.cxx b/Source/cmGeneratorExpression.cxx
index 2b4d955..7fc1464 100644
--- a/Source/cmGeneratorExpression.cxx
+++ b/Source/cmGeneratorExpression.cxx
@@ -97,6 +97,7 @@ const char *cmCompiledGeneratorExpression::Evaluate(
context.Quiet = quiet;
context.HadError = false;
context.HadContextSensitiveCondition = false;
+ context.HadHeadSensitiveCondition = false;
context.HeadTarget = headTarget;
context.EvaluateForBuildsystem = this-EvaluateForBuildsystem;
context.CurrentTarget = currentTarget ? currentTarget : headTarget;
@@ -124,6 +125,7 @@ const char *cmCompiledGeneratorExpression::Evaluate(
if (!context.HadError)
{
this-HadContextSensitiveCondition = context.HadContextSensitiveCondition;
+this-HadHeadSensitiveCondition = context.HadHeadSensitiveCondition;
}
this-DependTargets = context.DependTargets;
@@ -137,6 +139,7 @@
cmCompiledGeneratorExpression::cmCompiledGeneratorExpression(
const std::string input)
: Backtrace(backtrace), Input(input),
HadContextSensitiveCondition(false),
+HadHeadSensitiveCondition(false),
EvaluateForBuildsystem(false)
{
cmGeneratorExpressionLexer l;
diff --git a/Source/cmGeneratorExpression.h b/Source/cmGeneratorExpression.h
index 324d23c..b952520 100644
--- a/Source/cmGeneratorExpression.h
+++ b/Source/cmGeneratorExpression.h
@@ -111,6 +111,10 @@ public:
{
return this-HadContextSensitiveCondition;
}
+ bool GetHadHeadSensitiveCondition() const
+ {
+return this-HadHeadSensitiveCondition;
+ }
void SetEvaluateForBuildsystem(bool eval)
{
@@ -141,6 +145,7 @@ private:
MaxLanguageStandard;
mutable std::string Output;
mutable bool HadContextSensitiveCondition;
+ mutable bool HadHeadSensitiveCondition;
bool EvaluateForBuildsystem;
};
diff --git a/Source/cmGeneratorExpressionEvaluator.cxx
b/Source/cmGeneratorExpressionEvaluator.cxx
index 28879f1..3d03ece 100644
--- a/Source/cmGeneratorExpressionEvaluator.cxx
+++ b/Source/cmGeneratorExpressionEvaluator.cxx
@@ -840,6 +840,10 @@ getLinkedTargetsContent(
{
context-HadContextSensitiveCondition = true;
}
+if (cge-GetHadHeadSensitiveCondition())
+ {
+ context-HadHeadSensitiveCondition = true;
+ }
}
linkedTargetsContent =
cmGeneratorExpression::StripEmptyListElements(linkedTargetsContent);
@@ -871,6 +875,10 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
cmTarget const* target = context-HeadTarget;
std::string propertyName = *parameters.begin();
+if (parameters.size() == 1)
+ {
+ context-HadHeadSensitiveCondition = true;
+ }
if (!target parameters.size() == 1)
{
reportError(context, content-GetOriginalExpression(),
@@ -1313,6 +1321,7 @@ static const struct CompileFeaturesNode : public
cmGeneratorExpressionNode
not be used with add_custom_command or add_custom_target.);
return std::string();
}
+context-HadHeadSensitiveCondition = true;
typedef std::mapstd::string, std::vectorstd::string LangMap;
static LangMap availableFeatures;
@@ -1446,6 +1455,7 @@ static const struct TargetPolicyNode : public
[Cmake-commits] CMake branch, next, updated. v3.0.0-4398-g5032630
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 5032630277c8d8097404fe5cef6772d93793f06e (commit)
via b154a32dcd10cbf1653c3ba3e803edf86ff5def7 (commit)
from fe74f3b9dc321a3340b9e96646a193469d0be653 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5032630277c8d8097404fe5cef6772d93793f06e
commit 5032630277c8d8097404fe5cef6772d93793f06e
Merge: fe74f3b b154a32
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 10:59:05 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 21 10:59:05 2014 -0400
Merge topic 'target-drop-build-setting-cache' into next
b154a32d Revert topic 'target-drop-build-setting-cache'
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b154a32dcd10cbf1653c3ba3e803edf86ff5def7
commit b154a32dcd10cbf1653c3ba3e803edf86ff5def7
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 11:00:09 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jul 21 11:00:09 2014 -0400
Revert topic 'target-drop-build-setting-cache'
It contained changes not ready for testing.
diff --git a/Source/cmGeneratorExpression.cxx b/Source/cmGeneratorExpression.cxx
index 7fc1464..2b4d955 100644
--- a/Source/cmGeneratorExpression.cxx
+++ b/Source/cmGeneratorExpression.cxx
@@ -97,7 +97,6 @@ const char *cmCompiledGeneratorExpression::Evaluate(
context.Quiet = quiet;
context.HadError = false;
context.HadContextSensitiveCondition = false;
- context.HadHeadSensitiveCondition = false;
context.HeadTarget = headTarget;
context.EvaluateForBuildsystem = this-EvaluateForBuildsystem;
context.CurrentTarget = currentTarget ? currentTarget : headTarget;
@@ -125,7 +124,6 @@ const char *cmCompiledGeneratorExpression::Evaluate(
if (!context.HadError)
{
this-HadContextSensitiveCondition = context.HadContextSensitiveCondition;
-this-HadHeadSensitiveCondition = context.HadHeadSensitiveCondition;
}
this-DependTargets = context.DependTargets;
@@ -139,7 +137,6 @@
cmCompiledGeneratorExpression::cmCompiledGeneratorExpression(
const std::string input)
: Backtrace(backtrace), Input(input),
HadContextSensitiveCondition(false),
-HadHeadSensitiveCondition(false),
EvaluateForBuildsystem(false)
{
cmGeneratorExpressionLexer l;
diff --git a/Source/cmGeneratorExpression.h b/Source/cmGeneratorExpression.h
index b952520..324d23c 100644
--- a/Source/cmGeneratorExpression.h
+++ b/Source/cmGeneratorExpression.h
@@ -111,10 +111,6 @@ public:
{
return this-HadContextSensitiveCondition;
}
- bool GetHadHeadSensitiveCondition() const
- {
-return this-HadHeadSensitiveCondition;
- }
void SetEvaluateForBuildsystem(bool eval)
{
@@ -145,7 +141,6 @@ private:
MaxLanguageStandard;
mutable std::string Output;
mutable bool HadContextSensitiveCondition;
- mutable bool HadHeadSensitiveCondition;
bool EvaluateForBuildsystem;
};
diff --git a/Source/cmGeneratorExpressionEvaluator.cxx
b/Source/cmGeneratorExpressionEvaluator.cxx
index 3d03ece..28879f1 100644
--- a/Source/cmGeneratorExpressionEvaluator.cxx
+++ b/Source/cmGeneratorExpressionEvaluator.cxx
@@ -840,10 +840,6 @@ getLinkedTargetsContent(
{
context-HadContextSensitiveCondition = true;
}
-if (cge-GetHadHeadSensitiveCondition())
- {
- context-HadHeadSensitiveCondition = true;
- }
}
linkedTargetsContent =
cmGeneratorExpression::StripEmptyListElements(linkedTargetsContent);
@@ -875,10 +871,6 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
cmTarget const* target = context-HeadTarget;
std::string propertyName = *parameters.begin();
-if (parameters.size() == 1)
- {
- context-HadHeadSensitiveCondition = true;
- }
if (!target parameters.size() == 1)
{
reportError(context, content-GetOriginalExpression(),
@@ -1321,7 +1313,6 @@ static const struct CompileFeaturesNode : public
cmGeneratorExpressionNode
not be used with add_custom_command or add_custom_target.);
return std::string();
}
-context-HadHeadSensitiveCondition = true;
typedef std::mapstd::string, std::vectorstd::string LangMap;
static LangMap availableFeatures;
@@ -1455,7 +1446,6 @@ static const struct TargetPolicyNode : public
cmGeneratorExpressionNode
}
context-HadContextSensitiveCondition = true;
-context-HadHeadSensitiveCondition = true;
for (size_t i = 1; i
[Cmake-commits] CMake branch, next, updated. v3.0.0-4401-g26f4d69
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 26f4d69d567e6ae3b88821a4f25817c5876f6a1c (commit)
via 133cd996d161cd349e67d90052ac4e20d9488620 (commit)
via a4d58722a47b3712d1f78683371f88a3b6182a59 (commit)
from 5032630277c8d8097404fe5cef6772d93793f06e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26f4d69d567e6ae3b88821a4f25817c5876f6a1c
commit 26f4d69d567e6ae3b88821a4f25817c5876f6a1c
Merge: 5032630 133cd99
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 11:04:04 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 21 11:04:04 2014 -0400
Merge topic 'target-drop-build-setting-cache' into next
133cd996 cmTarget: Drop internal cache of build properties
a4d58722 cmTarget: Drop internal cache of link interface usage requirements
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=133cd996d161cd349e67d90052ac4e20d9488620
commit 133cd996d161cd349e67d90052ac4e20d9488620
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Jul 18 14:04:56 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jul 21 11:00:34 2014 -0400
cmTarget: Drop internal cache of build properties
These use a huge amount of memory that accumulates as generation
proceeds. On the Unix Makefiles generator, only GetIncludeDirectories
and GetCompileDefinitions are even called more than once per target
(once for build files, once for dependency scanning preprocessor info).
Another approach will be needed to avoid duplicate computation in the
cases where it does occur.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index a812df7..9d00591 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -196,11 +196,9 @@ public:
public:
TargetPropertyEntry(cmsys::auto_ptrcmCompiledGeneratorExpression cge,
cmLinkImplItem const item = NoLinkImplItem)
- : ge(cge), Cached(false), LinkImplItem(item)
+ : ge(cge), LinkImplItem(item)
{}
const cmsys::auto_ptrcmCompiledGeneratorExpression ge;
-std::vectorstd::string CachedEntries;
-bool Cached;
cmLinkImplItem const LinkImplItem;
};
std::vectorTargetPropertyEntry* IncludeDirectoriesEntries;
@@ -635,49 +633,37 @@ static bool processSources(cmTarget const* tgt,
for (std::vectorcmTargetInternals::TargetPropertyEntry*::const_iterator
it = entries.begin(), end = entries.end(); it != end; ++it)
{
-bool cacheSources = false;
-std::vectorstd::string entrySources = (*it)-CachedEntries;
-if(entrySources.empty())
+std::vectorstd::string entrySources;
+cmSystemTools::ExpandListArgument((*it)-ge-Evaluate(mf,
+ config,
+ false,
+ tgt,
+ tgt,
+ dagChecker),
+entrySources);
+
+if ((*it)-ge-GetHadContextSensitiveCondition())
{
- cmSystemTools::ExpandListArgument((*it)-ge-Evaluate(mf,
-config,
-false,
-tgt,
-tgt,
-dagChecker),
- entrySources);
+ contextDependent = true;
+ }
- if ((*it)-ge-GetHadContextSensitiveCondition())
-{
-contextDependent = true;
-}
- else if (mf-IsGeneratingBuildSystem())
-{
-cacheSources = true;
-}
+for(std::vectorstd::string::iterator i = entrySources.begin();
+i != entrySources.end(); ++i)
+ {
+ std::string src = *i;
- for(std::vectorstd::string::iterator i = entrySources.begin();
- i != entrySources.end(); ++i)
+ cmSourceFile* sf = mf-GetOrCreateSource(src);
+ std::string e;
+ src = sf-GetFullPath(e);
+ if(src.empty())
{
-std::string src = *i;
-
-cmSourceFile* sf = mf-GetOrCreateSource(src);
-std::string e;
-src = sf-GetFullPath(e);
-if(src.empty())
+if(!e.empty())
{
- if(!e.empty())
-{
-cmake* cm = mf-GetCMakeInstance();
-cm-IssueMessage(cmake::FATAL_ERROR, e,
-tgt-GetBacktrace());
-}
- return contextDependent;
+
[Cmake-commits] CMake branch, next, updated. v3.0.0-4404-gc7be55d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via c7be55d48bcf49ef83945b9fd530923ca648edc4 (commit) via 846e56db5734f30f77bb078f13eec25917b5e693 (commit) via a4540a64155f08ccbd919c8106c5674d048dcd0e (commit) from 26f4d69d567e6ae3b88821a4f25817c5876f6a1c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7be55d48bcf49ef83945b9fd530923ca648edc4 commit c7be55d48bcf49ef83945b9fd530923ca648edc4 Merge: 26f4d69 846e56d Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 11:55:30 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 11:55:30 2014 -0400 Merge topic 'deprecated-properties' into next 846e56db Help: List POST/PRE_INSTALL_SCRIPT properties as deprecated. a4540a64 Help: Document COMPILE_DEFINITIONS_Config properties as deprecated. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=846e56db5734f30f77bb078f13eec25917b5e693 commit 846e56db5734f30f77bb078f13eec25917b5e693 Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 17:53:56 2014 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Mon Jul 21 17:53:56 2014 +0200 Help: List POST/PRE_INSTALL_SCRIPT properties as deprecated. diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 2075d73..f6a650e 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -207,9 +207,7 @@ Properties on Targets /prop_tgt/PDB_OUTPUT_DIRECTORY_CONFIG /prop_tgt/PDB_OUTPUT_DIRECTORY /prop_tgt/POSITION_INDEPENDENT_CODE - /prop_tgt/POST_INSTALL_SCRIPT /prop_tgt/PREFIX - /prop_tgt/PRE_INSTALL_SCRIPT /prop_tgt/PRIVATE_HEADER /prop_tgt/PROJECT_LABEL /prop_tgt/PUBLIC_HEADER @@ -342,6 +340,8 @@ Properties on Targets :maxdepth: 1 /prop_tgt/COMPILE_DEFINITIONS_CONFIG + /prop_tgt/POST_INSTALL_SCRIPT + /prop_tgt/PRE_INSTALL_SCRIPT Properties on Source Files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4540a64155f08ccbd919c8106c5674d048dcd0e commit a4540a64155f08ccbd919c8106c5674d048dcd0e Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 17:44:46 2014 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Mon Jul 21 17:44:46 2014 +0200 Help: Document COMPILE_DEFINITIONS_Config properties as deprecated. diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index e4546c1..2075d73 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -7,8 +7,12 @@ cmake-properties(7) .. contents:: +Normal Properties += +These properties may be used freely in CMake projects. + Properties of Global Scope -== +^^ .. toctree:: :maxdepth: 1 @@ -42,7 +46,7 @@ Properties of Global Scope /prop_gbl/USE_FOLDERS Properties on Directories -= +^ .. toctree:: :maxdepth: 1 @@ -51,7 +55,6 @@ Properties on Directories /prop_dir/CACHE_VARIABLES /prop_dir/CLEAN_NO_CUSTOM /prop_dir/CMAKE_CONFIGURE_DEPENDS - /prop_dir/COMPILE_DEFINITIONS_CONFIG /prop_dir/COMPILE_DEFINITIONS /prop_dir/COMPILE_OPTIONS /prop_dir/DEFINITIONS @@ -74,7 +77,7 @@ Properties on Directories /prop_dir/VS_GLOBAL_SECTION_PRE_section Properties on Targets -= +^ .. toctree:: :maxdepth: 1 @@ -101,7 +104,6 @@ Properties on Targets /prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX /prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN /prop_tgt/COMPATIBLE_INTERFACE_STRING - /prop_tgt/COMPILE_DEFINITIONS_CONFIG /prop_tgt/COMPILE_DEFINITIONS /prop_tgt/COMPILE_FEATURES /prop_tgt/COMPILE_FLAGS @@ -245,7 +247,7 @@ Properties on Targets /prop_tgt/XCODE_ATTRIBUTE_an-attribute Properties on Tests -=== +^^^ .. toctree:: :maxdepth: 1 @@ -269,7 +271,7 @@ Properties on Tests /prop_test/WORKING_DIRECTORY Properties on Source Files -== +^^ .. toctree:: :maxdepth: 1 @@ -277,7 +279,6 @@ Properties on Source Files /prop_sf/ABSTRACT /prop_sf/AUTOUIC_OPTIONS /prop_sf/AUTORCC_OPTIONS - /prop_sf/COMPILE_DEFINITIONS_CONFIG /prop_sf/COMPILE_DEFINITIONS /prop_sf/COMPILE_FLAGS /prop_sf/EXTERNAL_OBJECT @@ -297,7 +298,7 @@ Properties on Source Files /prop_sf/XCODE_LAST_KNOWN_FILE_TYPE Properties on Cache Entries -=== +^^^ ..
[Cmake-commits] CMake branch, next, updated. v3.0.0-4411-g143931d
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 143931d04181a6b192da26c3e3996d9cba0eb04d (commit)
via 7b743a2e761783f930de41db3f7a706b065bbb2e (commit)
via 807e4ffeefb0e10ef0546e0eb7383f3d5533809b (commit)
via 46099b82ed71394f1dc6e0bbb91704d274edab7d (commit)
via 438d9c7c822f42c4fccd77a47b1a32f52a87e617 (commit)
via fe665fdda8986b3af061ec91a7ab5fbe8f606e4f (commit)
via 9d13e1679f2b52e88748a710edd201ed9fba7447 (commit)
from c7be55d48bcf49ef83945b9fd530923ca648edc4 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143931d04181a6b192da26c3e3996d9cba0eb04d
commit 143931d04181a6b192da26c3e3996d9cba0eb04d
Merge: c7be55d 7b743a2
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 13:05:32 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 21 13:05:32 2014 -0400
Merge topic 'genex-head-sensitive-conditions' into next
7b743a2e cmTarget: Avoid re-computing head-independent link interfaces
807e4ffe Genex: Track whether an expression depends on the 'head' target
46099b82 cmTarget: Move ComputeLinkImplementation* to internals
438d9c7c cmTarget: Re-order link interface map lookup logic
fe665fdd cmTarget: Refactor link interface map storage
9d13e167 cmTarget: Remove duplicate link interface map
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b743a2e761783f930de41db3f7a706b065bbb2e
commit 7b743a2e761783f930de41db3f7a706b065bbb2e
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 21 13:04:04 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jul 21 13:04:04 2014 -0400
cmTarget: Avoid re-computing head-independent link interfaces
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 353a3a6..ca24d2d 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -114,10 +114,12 @@ public:
{
OptionalLinkInterface():
LibrariesDone(false), AllDone(false),
- Exists(false), ExplicitLibraries(0) {}
+ Exists(false), HadHeadSensitiveCondition(false),
+ ExplicitLibraries(0) {}
bool LibrariesDone;
bool AllDone;
bool Exists;
+bool HadHeadSensitiveCondition;
const char* ExplicitLibraries;
};
void ComputeLinkInterface(cmTarget const* thisTarget,
@@ -151,9 +153,11 @@ public:
struct OptionalLinkImplementation: public cmTarget::LinkImplementation
{
OptionalLinkImplementation():
- LibrariesDone(false), LanguagesDone(false) {}
+ LibrariesDone(false), LanguagesDone(false),
+ HadHeadSensitiveCondition(false) {}
bool LibrariesDone;
bool LanguagesDone;
+bool HadHeadSensitiveCondition;
};
void ComputeLinkImplementationLibraries(cmTarget const* thisTarget,
const std::string config,
@@ -3435,7 +3439,8 @@ void cmTarget::ExpandLinkItems(std::string const prop,
std::string const config,
cmTarget const* headTarget,
bool usage_requirements_only,
- std::vectorcmLinkItem items) const
+ std::vectorcmLinkItem items,
+ bool hadHeadSensitiveCondition) const
{
cmGeneratorExpression ge;
cmGeneratorExpressionDAGChecker dagChecker(this-GetName(), prop, 0, 0);
@@ -3446,13 +3451,15 @@ void cmTarget::ExpandLinkItems(std::string const prop,
dagChecker.SetTransitivePropertiesOnly();
}
std::vectorstd::string libs;
- cmSystemTools::ExpandListArgument(ge.Parse(value)-Evaluate(
+ cmsys::auto_ptrcmCompiledGeneratorExpression cge = ge.Parse(value);
+ cmSystemTools::ExpandListArgument(cge-Evaluate(
this-Makefile,
config,
false,
headTarget,
this, dagChecker), libs);
this-LookupLinkItems(libs, items);
+ hadHeadSensitiveCondition = cge-GetHadHeadSensitiveCondition();
}
//
@@ -5757,6 +5764,14 @@ cmTarget::LinkInterface const*
cmTarget::GetLinkInterface(
std::string CONFIG = cmSystemTools::UpperCase(config);
cmTargetInternals::HeadToLinkInterfaceMap hm =
this-Internal-LinkInterfaceMap[CONFIG];
+
+ // If the link interface does not depend on the head target
+ // then return the one we computed first.
+ if(!hm.empty() !hm.begin()-second.HadHeadSensitiveCondition)
+
[Cmake-commits] CMake branch, next, updated. v3.0.0-4414-g64d13c1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 64d13c146c0470cf46798d10146cadedf9a25445 (commit) via 8d8d4404f66d646d5ee50a7a945e669f3816171d (commit) via 8322676382b9a9443bb892044f7421e88ba7d21c (commit) from 143931d04181a6b192da26c3e3996d9cba0eb04d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64d13c146c0470cf46798d10146cadedf9a25445 commit 64d13c146c0470cf46798d10146cadedf9a25445 Merge: 143931d 8d8d440 Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 13:44:19 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 13:44:19 2014 -0400 Merge topic 'deprecated-properties' into next 8d8d4404 Help: Add missing extra spaces 83226763 Help: Flatten hierarchy in property documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d8d4404f66d646d5ee50a7a945e669f3816171d commit 8d8d4404f66d646d5ee50a7a945e669f3816171d Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 19:38:22 2014 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Mon Jul 21 19:41:52 2014 +0200 Help: Add missing extra spaces diff --git a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst index af18d7b..a6af45f 100644 --- a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,7 +1,7 @@ COMPILE_DEFINITIONS_CONFIG -Ignored. See CMake Policy :policy:`CMP0043`. +Ignored. See CMake Policy :policy:`CMP0043`. Per-configuration preprocessor definitions in a directory. diff --git a/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst index 4920f58..8487076 100644 --- a/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,7 +1,7 @@ COMPILE_DEFINITIONS_CONFIG -Ignored. See CMake Policy :policy:`CMP0043`. +Ignored. See CMake Policy :policy:`CMP0043`. Per-configuration preprocessor definitions on a source file. diff --git a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst index 1dba356..84bd5e4 100644 --- a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,7 +1,7 @@ COMPILE_DEFINITIONS_CONFIG -Ignored. See CMake Policy :policy:`CMP0043`. +Ignored. See CMake Policy :policy:`CMP0043`. Per-configuration preprocessor definitions on a target. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8322676382b9a9443bb892044f7421e88ba7d21c commit 8322676382b9a9443bb892044f7421e88ba7d21c Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 19:36:18 2014 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Mon Jul 21 19:41:51 2014 +0200 Help: Flatten hierarchy in property documentation diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index f6a650e..17dadc2 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -7,12 +7,8 @@ cmake-properties(7) .. contents:: -Normal Properties -= -These properties may be used freely in CMake projects. - Properties of Global Scope -^^ +== .. toctree:: :maxdepth: 1 @@ -46,7 +42,7 @@ Properties of Global Scope /prop_gbl/USE_FOLDERS Properties on Directories -^ += .. toctree:: :maxdepth: 1 @@ -77,7 +73,7 @@ Properties on Directories /prop_dir/VS_GLOBAL_SECTION_PRE_section Properties on Targets -^ += .. toctree:: :maxdepth: 1 @@ -245,7 +241,7 @@ Properties on Targets /prop_tgt/XCODE_ATTRIBUTE_an-attribute Properties on Tests -^^^ +=== .. toctree:: :maxdepth: 1 @@ -269,7 +265,7 @@ Properties on Tests /prop_test/WORKING_DIRECTORY Properties on Source Files -^^ +== .. toctree:: :maxdepth: 1 @@ -296,7 +292,7 @@ Properties on Source Files /prop_sf/XCODE_LAST_KNOWN_FILE_TYPE Properties on Cache Entries -^^^ +=== .. toctree:: :maxdepth: 1 @@ -309,7 +305,7 @@ Properties on Cache Entries /prop_cache/VALUE Properties on Installed Files -^ += .. toctree:: :maxdepth: 1 @@ -318,14 +314,8 @@ Properties on
[Cmake-commits] CMake branch, next, updated. v3.0.0-4416-g2031072
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 2031072957ad0de5f4e447f34075d1f95bd609eb (commit) via 5bbec4e3982d25c3514246d691a5b15cacfd5daa (commit) from 64d13c146c0470cf46798d10146cadedf9a25445 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2031072957ad0de5f4e447f34075d1f95bd609eb commit 2031072957ad0de5f4e447f34075d1f95bd609eb Merge: 64d13c1 5bbec4e Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 13:49:18 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jul 21 13:49:18 2014 -0400 Merge topic 'deprecated-properties' into next 5bbec4e3 Help: Document deprecated properties. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5bbec4e3982d25c3514246d691a5b15cacfd5daa commit 5bbec4e3982d25c3514246d691a5b15cacfd5daa Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Mon Jul 21 17:44:46 2014 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Mon Jul 21 19:48:48 2014 +0200 Help: Document deprecated properties. Document the COMPILE_DEFINITIONS_Config properties as deprecated. Add new sections for deprecated properties and move POST_INSTALL_SCRIPT and PRE_INSTALL_SCRIPT there as well. diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index e4546c1..17dadc2 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -51,7 +51,6 @@ Properties on Directories /prop_dir/CACHE_VARIABLES /prop_dir/CLEAN_NO_CUSTOM /prop_dir/CMAKE_CONFIGURE_DEPENDS - /prop_dir/COMPILE_DEFINITIONS_CONFIG /prop_dir/COMPILE_DEFINITIONS /prop_dir/COMPILE_OPTIONS /prop_dir/DEFINITIONS @@ -101,7 +100,6 @@ Properties on Targets /prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX /prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN /prop_tgt/COMPATIBLE_INTERFACE_STRING - /prop_tgt/COMPILE_DEFINITIONS_CONFIG /prop_tgt/COMPILE_DEFINITIONS /prop_tgt/COMPILE_FEATURES /prop_tgt/COMPILE_FLAGS @@ -205,9 +203,7 @@ Properties on Targets /prop_tgt/PDB_OUTPUT_DIRECTORY_CONFIG /prop_tgt/PDB_OUTPUT_DIRECTORY /prop_tgt/POSITION_INDEPENDENT_CODE - /prop_tgt/POST_INSTALL_SCRIPT /prop_tgt/PREFIX - /prop_tgt/PRE_INSTALL_SCRIPT /prop_tgt/PRIVATE_HEADER /prop_tgt/PROJECT_LABEL /prop_tgt/PUBLIC_HEADER @@ -277,7 +273,6 @@ Properties on Source Files /prop_sf/ABSTRACT /prop_sf/AUTOUIC_OPTIONS /prop_sf/AUTORCC_OPTIONS - /prop_sf/COMPILE_DEFINITIONS_CONFIG /prop_sf/COMPILE_DEFINITIONS /prop_sf/COMPILE_FLAGS /prop_sf/EXTERNAL_OBJECT @@ -317,3 +312,32 @@ Properties on Installed Files /prop_inst/CPACK_NEVER_OVERWRITE.rst /prop_inst/CPACK_PERMANENT.rst + + +Deprecated Properties on Directories += + +.. toctree:: + :maxdepth: 1 + + /prop_dir/COMPILE_DEFINITIONS_CONFIG + + +Deprecated Properties on Targets + + +.. toctree:: + :maxdepth: 1 + + /prop_tgt/COMPILE_DEFINITIONS_CONFIG + /prop_tgt/POST_INSTALL_SCRIPT + /prop_tgt/PRE_INSTALL_SCRIPT + + +Deprecated Properties on Source Files += + +.. toctree:: + :maxdepth: 1 + + /prop_sf/COMPILE_DEFINITIONS_CONFIG diff --git a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst index c22606b..a6af45f 100644 --- a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,6 +1,8 @@ COMPILE_DEFINITIONS_CONFIG +Ignored. See CMake Policy :policy:`CMP0043`. + Per-configuration preprocessor definitions in a directory. This is the configuration-specific version of :prop_dir:`COMPILE_DEFINITIONS` diff --git a/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst index e695f38..8487076 100644 --- a/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_sf/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,6 +1,8 @@ COMPILE_DEFINITIONS_CONFIG +Ignored. See CMake Policy :policy:`CMP0043`. + Per-configuration preprocessor definitions on a source file. This is the configuration-specific version of COMPILE_DEFINITIONS. diff --git a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst index e359d2c..84bd5e4 100644 --- a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst +++ b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst @@ -1,6 +1,8 @@ COMPILE_DEFINITIONS_CONFIG +Ignored. See CMake Policy
[Cmake-commits] CMake branch, master, updated. v3.0.0-1467-g08bb09a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 08bb09a944ecccb5d5f25c847be7b30a70ccf7c4 (commit) from 23ec3738a0bafd23a9d37fc72e7183e8dc84a4ac (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08bb09a944ecccb5d5f25c847be7b30a70ccf7c4 commit 08bb09a944ecccb5d5f25c847be7b30a70ccf7c4 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Jul 22 00:01:08 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Jul 22 00:01:08 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index c034126..44737b8 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140721) +set(CMake_VERSION_PATCH 20140722) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
