Re: [cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
Stephen Kelly wrote: In the Allow target_link_libraries with IMPORTED targets. commit message, it says This requires policy CMP0019 to be NEW. However, I don't see any checks enforcing that or documentation. That may be a left-over from a previous version of the patch. That part of the commit message (or at least the thinking behind it) dates from when the patches I was writing only read the INTERFACE_LINK_LIBRARIES property on IMPORTED targets if the policy was NEW. That is since changed, so I've removed that note in a force-push to my clone. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting include directories via target_link_libraries() ?
Stephen Kelly wrote: I haven't tried to analyse how much of the complexity is due to whether target_use_targets or target_link_libraries is used. I think the harder parts of this topic so far have been related to exports. Like I said though, I haven't analysed how much of the exports complexity comes from the use of tll(). I've split out the part of the commit that changes tll(), and I think the complexity remains in the part that would be essential even with a new command. If target_link_libraries never sets the new properties (LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES), the question in the 'link implementation is link interface' case remains: Should the exported link interface be populated by iface.Libraries (as set by tll()), or by the LINK_LIBRARIES property (as populated by a new command). We can't really just check if LINK_LIBRARIES exists and use it if so. That would mean that if the user starts with this: target_link_libraries(foo bar) bar will be in the link interface when exported. If they then add a line: target_link_libraries(foo bar) target_use_targets(foo bing) bar will no longer be in the link interface when exported. Only bing will be. I think that would be even more complex for the user, and probably even more complex for us to implement and review, emit appropriate warnings etc. Even if we have a policy for when people use the old and new command with the same foo, people will use both tll() and the new command in the same project (with different targets), and that will be confusing for them. That's also a reason not to add a new command, I think. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INCLUDE_DIRECTORIES variable expansion
Brad King wrote: IMO the policy is worthwhile anyway. I reverted your previous topic using the above approach and replaced it with this: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a0a5c78 I suggest renaming the new policy to the CMP0019 spot and not reserving any policies that won't be in the same release as that commit. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
Brad King wrote: Brad King wrote: How can we ever stop exporting the old interface when it comes from the link implementation? Now even projects that have never touched LINK_INTERFACE_LIBRARIES will have to be fixed to manually set it to a copy of the link implementation in order to remain compatible with older CMake versions once they set the policy to NEW. I'm not currently sure whether this is okay. I've added another patch to my clone to solve this problem: Export link implementation as old link interface if it does not contain generator expressions. That way, target_link_libraries(foo bar) will export the old and new link interfaces, and target_link_libraries(foo $1:bar) will export only the new one, which is appropriate anyway because only that can handle the generator expressions. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INCLUDE_DIRECTORIES variable expansion
On 12/07/2012 06:12 AM, Stephen Kelly wrote: Brad King wrote: IMO the policy is worthwhile anyway. I reverted your previous topic using the above approach and replaced it with this: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a0a5c78 I suggest renaming the new policy to the CMP0019 spot and not reserving any policies that won't be in the same release as that commit. Okay. I added this commit to 'next' to rename it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3953103 though that will never go to 'master'. Instead I squashed it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=711b63f7 Please rebase your other topics and renumber the policies. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
On 12/06/2012 05:04 PM, Stephen Kelly wrote: I'd prefer the wiki. I think it would make sense to use/update/add a design section to: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements or we could create a new page otherwise. It is version controlled etc. Okay. Please add discussion there about the changes intended to be made in the add-INTERFACE_LINK_LIBRARIES topic. We need to cover code examples for existing behavior for all target and export/import types and how they will be handled by the topic. It also needs discussion of all tll modes, LINK_INTERFACE_LIBRARIES, LINK_LIBRARIES, INTERFACE_LINK_LIBRARIES, etc. Look at the ExportImport test to see most cases currently handled. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Policy for INTERFACE_LINK_LIBRARIES
On 12/06/2012 05:00 PM, Stephen Kelly wrote:
Currently it doesn't seem to work. Using current master with this:
add_library(picon SHARED libone.cpp)
add_library(picoff SHARED libtwo.cpp)
target_link_libraries(picoff picon)
export(TARGETS
picon
NAMESPACE foo_
FILE foo_iface.cmake
)
export(TARGETS
picoff
NAMESPACE bar_
FILE bar_iface.cmake
)
Results in an error:
CMake Error at CMakeLists.txt:99 (export):
export called with target picoff which requires target picon that is
not in the export list.
IIRC the topic that added dependent export support was only
finished for the install(EXPORT) command and not for export().
It added a test for the install case mixing namespaces:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955b9662
It appears to work. The install tree contains one export with:
# Create imported target Req::testLibRequired
ADD_LIBRARY(Req::testLibRequired STATIC IMPORTED)
...
# Import target Req::testLibRequired for configuration Debug
SET_PROPERTY(TARGET Req::testLibRequired APPEND PROPERTY
IMPORTED_CONFIGURATIONS DEBUG)
SET_TARGET_PROPERTIES(Req::testLibRequired PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG C
IMPORTED_LOCATION_DEBUG ${_IMPORT_PREFIX}/lib/libtestLibRequired.a
)
and a dependent export with:
# Create imported target testLibDepends
ADD_LIBRARY(testLibDepends STATIC IMPORTED)
...
# Make sure the targets which have been exported in some other
# export set exist.
IF(NOT TARGET Req::testLibRequired )
IF(CMAKE_FIND_PACKAGE_NAME)
SET( ${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
SET( ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE Required imported
target \Req::testLibRequired\ not found ! )
ELSE()
MESSAGE(FATAL_ERROR Required imported target \Req::testLibRequired\ not
found ! )
ENDIF()
ENDIF()
...
# Import target testLibDepends for configuration Debug
SET_PROPERTY(TARGET testLibDepends APPEND PROPERTY IMPORTED_CONFIGURATIONS
DEBUG)
SET_TARGET_PROPERTIES(testLibDepends PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG C
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Req::testLibRequired
IMPORTED_LOCATION_DEBUG ${_IMPORT_PREFIX}/lib/libtestLibDepends.a
)
This will need to work in the new interface.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Global flags for creating static libraries
On 12/07/2012 12:04 AM, Evan Pipho wrote: I am looking for a way to set global flags for the librarian when creating static libraries, similar to CMAKE_SHARED_LINKER_FLAGS or CMAKE_EXE_LINKER_FLAGS. This would facilitate things like using 3rd party libraries that already use cmake without having to modify their CMakeLists.txt to set these flags. I found http://public.kitware.com/Bug/view.php?id=10094 which mentions using CMAKE_STATIC_LINKER_FLAGS as well as this fairly old thread http://www.cmake.org/pipermail/cmake/2009-October/032563.html also mentioning this. Has there been any progress on this feature? If not, does a feature that exposes a CMAKE_STATIC_LINKER_FLAGS (and CMAKE_STATIC_LINKER_FLAGS_TARGET) which are then passed to the librarian (ar, lib.exe etx) make sense? I think this would be quite useful, especially for those of us that use cmake with visual studio. I would like to get the lists input, and if it is positive I would be interested in creating a patch to add this functionality. There is also this issue: http://www.cmake.org/Bug/view.php?id=10768 which was resolved here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe971d97 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3303dbc to add a STATIC_LIBRARY_FLAGS_CONFIG version of the property as requested in the mailing list thread you linked. What is still missing is the cache variables equivalent to CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS_CONFIG CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS_CONFIG CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS_CONFIG for static libraries. Following the above convention the names CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS_CONFIG make sense even though no linking is actually performed. To add them, look for places already handling the above variables and find the equivalents for static libs. You will need to modify at least: cmLocalGenerator::GetTargetFlags cmGlobalXCodeGenerator::CreateBuildSettings cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules cmLocalVisualStudio7Generator::OutputBuildTool cmLocalVisualStudio6Generator::WriteDSPHeader You will also need to modify the module Modules/CMakeCommonLanguageInclude.cmake to add the empty default cache entries. Finally, look in the cmDocumentVariables.cxx source file to add documentation. BTW, what kind of flags do you want to add to the librarian? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013251]: cmake -E tar file fails to extract some files correctly
The following issue is now in status NEW (again) == http://www.cmake.org/Bug/view.php?id=13251 == Reported By:sigma Assigned To: == Project:CMake Issue ID: 13251 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-05-27 07:37 EDT Last Modified: 2012-12-07 11:12 EST == Summary:cmake -E tar file fails to extract some files correctly Description: On certain tar.gz files cmake fails to extract them properly. I suspect this has to do with tar.gz files that have unix symlinks and are extracted on windows. One such file can be obtained from: http://openssl.org/source/openssl-1.0.1c.tar.gz When I try: cmake -E tar xf openssl-1.0.1c.tar.gz it fails on some files: CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/apps/md4.c CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/aes.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1_mac.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/asn1t.h CMake Error: Problem with archive_write_header(): Can't create '\' CMake Error: Current file:openssl-1.0.1c/include/openssl/bio.h CMake Error: Problem with archive_write_header(): Can't create '\' Using other extraction tools, e.g. cygwin or 7zip, this works without any problems. == Relationships ID Summary -- related to 0011176 cmake -E tar encodes long paths such ... related to 0010162 CPack Cannot create binary zip archive ... parent of 0011766 CPack using native TAR with adjustable ... == -- (0029571) Eric NOULARD (developer) - 2012-05-27 07:56 http://www.cmake.org/Bug/view.php?id=13251#c29571 -- I can extract this archive with CMake 2.8.8 on Linux (Debian Squeeze) without trouble... -- (0029572) Eric NOULARD (developer) - 2012-05-27 07:58 http://www.cmake.org/Bug/view.php?id=13251#c29572 -- You are right those files are symlinks. How do other tools like 7-zip handles those symlink on Windows? Do they create plain files which are a copy of the symlink target? Do they handle symlink in some way? -- (0029573) sigma (reporter) - 2012-05-27 10:48 http://www.cmake.org/Bug/view.php?id=13251#c29573 -- I created a test tar.gz with various file types to see what happens. Compress it on a linux box with tar (GNU tar) 1.26: tar -cpvzf cmake-tar-test.tar.gz cmake-tar-test/ The archive contains: cmake-tar-test/: total 12 drwxr-xr-x 2 root root 4096 May 27 16:44 bin drwxr-xr-x 2 root root 4096 May 27 17:23 links drwxr-xr-x 2 root root 4096 May 27 16:44 src cmake-tar-test/bin: total 100 -rwxr--r-- 1 root root 99328 May 27 16:43 main.exe cmake-tar-test/links: total 0 lrwxrwxrwx 1 root root 6 May 27 16:46 dir-link - ../src lrwxrwxrwx 1 root root 15 May 27 16:45 main.cpp - ../src/main.cpp lrwxrwxrwx 1 root root 15 May 27 16:45 main.exe - ../bin/main.exe lrwxrwxrwx 1 root root 13 May 27 16:45 main.h - ../src/main.h cmake-tar-test/src: total 8 -rwxr--r-- 1 root root 127 May 27 16:42 main.cpp -rwxr--r-- 1 root root 19 May 27 16:42 main.h So there is a mixture of symlinks to various filetypes and directories. main.exe was compiled on win7 and is a valid executable. I moved the files back to the Win7 machine to see how the different programs (7-zip, cygwin, cmake) behave. cmake log is here: cmake -E tar xvfz cmake-tar-test.tar.gz x cmake-tar-test/ x cmake-tar-test/links/ x
[cmake-developers] [CMake 0013780]: Continuous ctest does not work if executed in individual steps
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13780 == Reported By:Frank U. May Assigned To: == Project:CMake Issue ID: 13780 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-07 17:27 EST Last Modified: 2012-12-07 17:27 EST == Summary:Continuous ctest does not work if executed in individual steps Description: When running CTest continuous in individual steps every step following ContinuousUpdate is skipped. Basically it is a nice feature that continuous tests don't run, if there are no updates. However, it seems the current implementation breaks running continuous tests in individual steps. ContinuousUpdate works fine and reports the update. All following steps just report the site and the build name and do nothing else. Steps to Reproduce: 1.) Set up a CTest environment updating from a repository (I am using Git). 2.) From workspace A push an update to the repository. 3.) From workspace B run: ctest -C Release -D ContinuousStart ctest -C Release -D ContinuousUpdate ctest -C Release -D ContinuousConfigure ctest -C Release -D ContinuousBuild ctest -C Release -D ContinuousSubmit 4.) Note that ContinuousUpdate properly reports the update, while the following steps do nothing but report site and build name. 5.) Same issue, if you try: ctest -C Release --track Continuous -D Experimental[ALL_STEPS] 6.) Same issue if you try: ctest -C Release --track Continuous Master -D Continuous[ALL_STEPS] 7.) Same issue if you try: ctest -C Release --track Continuous Master -D Experimental[ALL_STEPS] 8.) Workaround: it works, if you try: ctest -C Release --track Commit Master -D Experimental[ALL_STEPS] Additional Information: As I am running continuous tests from my Git repository hook, the latter is a feasible workaround. But it is not nice at all; I would highly appreciate, if this could be fixed. Or if someone could point out, where I am showing off to be a dumb user. ;) To me it seems that the information that there was indeed an update from the repository gets lost between ContinuousUpdate and the following steps. == Issue History Date ModifiedUsername FieldChange == 2012-12-07 17:27 Frank U. May New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Global flags for creating static libraries
Thanks Brad, I will start taking a look this weekend. As for flags being passed to the librarian /LTCG for whole program optimization is probably the most common (and came up the most when I searched on this issue) but controlling warnings with /ignore and turning on warnings as errors (/wx) is also useful. On Fri, Dec 7, 2012 at 10:41 AM, Brad King brad.k...@kitware.com wrote: On 12/07/2012 12:04 AM, Evan Pipho wrote: I am looking for a way to set global flags for the librarian when creating static libraries, similar to CMAKE_SHARED_LINKER_FLAGS or CMAKE_EXE_LINKER_FLAGS. This would facilitate things like using 3rd party libraries that already use cmake without having to modify their CMakeLists.txt to set these flags. I found http://public.kitware.com/Bug/view.php?id=10094 which mentions using CMAKE_STATIC_LINKER_FLAGS as well as this fairly old thread http://www.cmake.org/pipermail/cmake/2009-October/032563.html also mentioning this. Has there been any progress on this feature? If not, does a feature that exposes a CMAKE_STATIC_LINKER_FLAGS (and CMAKE_STATIC_LINKER_FLAGS_TARGET) which are then passed to the librarian (ar, lib.exe etx) make sense? I think this would be quite useful, especially for those of us that use cmake with visual studio. I would like to get the lists input, and if it is positive I would be interested in creating a patch to add this functionality. There is also this issue: http://www.cmake.org/Bug/view.php?id=10768 which was resolved here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe971d97 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3303dbc to add a STATIC_LIBRARY_FLAGS_CONFIG version of the property as requested in the mailing list thread you linked. What is still missing is the cache variables equivalent to CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS_CONFIG CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS_CONFIG CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS_CONFIG for static libraries. Following the above convention the names CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS_CONFIG make sense even though no linking is actually performed. To add them, look for places already handling the above variables and find the equivalents for static libs. You will need to modify at least: cmLocalGenerator::GetTargetFlags cmGlobalXCodeGenerator::CreateBuildSettings cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules cmLocalVisualStudio7Generator::OutputBuildTool cmLocalVisualStudio6Generator::WriteDSPHeader You will also need to modify the module Modules/CMakeCommonLanguageInclude.cmake to add the empty default cache entries. Finally, look in the cmDocumentVariables.cxx source file to add documentation. BTW, what kind of flags do you want to add to the librarian? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Include_directories looks for Boost twice / Problem with if statement
Hi
Did you think about something like this:
ADD_DEFINITIONS (-DBOOST_ALL_NO_LIB)
SET (BOOST_ROOT $ENV{BOOST_ROOT})
SET (Boost_NO_SYSTEM_PATHS ON)
SET (Boost_USE_MULTITHREADED ON)
SET (Boost_USE_STATIC_RUNTIME OFF)
IF (TARGET parent)
FIND_PACKAGE (Boost 1.42.0 REQUIRED COMPONENTS system)
IF (Boost_FOUND)
LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES (parent ${Boost_LIBRARIES})
ENDIF ()
ENDIF (TARGET parent)
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Raymond Wan
Sent: Donnerstag, 6. Dezember 2012 18:45
To: cmake@cmake.org
Subject: [CMake] Include_directories looks for Boost twice / Problem with if
statement
Hi all,
I have two CMakeFile.txt's for a C++ project where one includes the other. In
both cases, I'm searching for Boost.
So, to make this easier, suppose I call one project parent and the other
child such that parent's CMakefile.txt has:
INCLUDE_DIRECTORIES (child)
where child is a subdirectory. Both have:
ADD_DEFINITIONS (-DBOOST_ALL_NO_LIB)
SET (BOOST_ROOT $ENV{BOOST_ROOT})
SET (Boost_NO_SYSTEM_PATHS ON)
SET (Boost_USE_MULTITHREADED ON)
SET (Boost_USE_STATIC_RUNTIME OFF)
FIND_PACKAGE (Boost 1.42.0 REQUIRED COMPONENTS system) IF (Boost_FOUND)
IF (TARGET parent)
LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES (parent ${Boost_LIBRARIES})
ENDIF (TARGET parent)
ENDIF ()
(In the subdirectory child, I check for the target child instead.)
The reason I have to repeat it twice is because both parent and child has a
main (). parent has the one for the entire project; if I want to do unit
testing on child, then I compile in child's build directory using its main.
I hope everything so far is ok. The problem is that when I run the
CMakeFile.txt of parent, it ends up checking for Boost twice.
There's no harm to it and I had left it alone for a while. Then, I thought I
could use an if statement inside child to prevent it from checking again.
Inside, child, none of these seem to work:
IF (NOT DEFINED Boost_FOUND)
IF (NOT Boost_FOUND)
So, while my question is about Boost, I guess it is irrelevant to boost...seems
to be a problem with my understanding of variables and if statements.
Any suggestion on what I'm doing wrong? Or am I going at it wrong and I need
to rethink what I'm doing?
Thank you!
Ray
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Determining debug release configurations
Hi,
On Fri, Dec 07, 2012 at 04:01:27AM -0500, cmake-requ...@cmake.org wrote:
Date: Thu, 6 Dec 2012 11:54:42 -0600
From: Robert Dailey rcdailey.li...@gmail.com
Does anyone have any code that can detect if a given configuration (by
name) is a debug or release configuration? This should work in both
single-configuration and multi-configuration generators.
For example, in Visual Studio:
Release - Release
MinSizeRel - Release
RelWithDebInfo - Release
Debug - Debug
Also any custom-added configurations should also work.
For single configuration generators, it should also work. Example:
CMAKE_BUILD_TYPE - MinSizeRel - should evaluate to Release.
CMAKE_BUILD_TYPE - Debug - should evaluate to Debug.
That's quite exactly what I'm doing right now (*dynamic*, *build-time*
calculation of required, *random-content* flag strings).
My solution (workaround?) is to provide functions to return a Win32 batch
scriptlet
to automatically map those config names to their equivalents,
then continue filling batch file with what I actually want to do,
making use of the %var% helpers which were nicely defined by the prepended
scriptlet code.
And of course that unfortunately means having to generate batch files to be
executed
rather than possibly adding custom targets with direkt cmake -E copy
handling.
But of course with a complex mapping of *dynamic* Debug/Release switching at
*build-time*
you most likely do need to have a build-executable foundation to get this
figured out properly.
Unless you write completely differing *static-content* scripts,
located in completely differing build tree prefixes of Debug/Release
configurations.
That's possibly a better solution since with dynamic switching
within an existing tree of payload files
you may end up getting unwanted build configuration conflicts.
Actual possible implementation: add a scripts_[BUILD_CONFIGURATION] dir
somewhere in binary dir, for all configurations that you of course know of at
configure time
(CMAKE_CONFIGURATION_TYPES).
Then configure-time generate
only-so-slightly differing scripts there, and invoke them using some
${CMAKE_SOME_BINARY_SUB_DIR}/scripts_${CMAKE_CFG_INTDIR}/my_script.bat
expression.
Helper functions suitable for *dynamic* (i.e., non-configure-time-generated)
evaluation of build-configuration-related values:
function(sbuild_configure_batch_var_name_debug_release_string_lower_get _out)
set(${_out} cfg_build_string_debug_release PARENT_SCOPE)
endfunction(sbuild_configure_batch_var_name_debug_release_string_lower_get _out)
function(sbuild_configure_batch_var_name_debug_yes_no_get _out)
set(${_out} cfg_build_debug_yes_no PARENT_SCOPE)
endfunction(sbuild_configure_batch_var_name_debug_yes_no_get _out)
function(sbuild_configure_batch_scriptlet_debug_flag_get
_out_debug_flag_content)
# Provide DOS batch syntax to support dynamic Debug/Release switching in
multi-configuration generators (Visual Studio) [see CMAKE_CONFIGURATION_TYPES]
# Within local handling, *always* query the authoritative helper for batch
variable names,
# to prevent any variable renaming issues from appearing.
sbuild_configure_batch_var_name_debug_yes_no_get(var_name_debug_yes_no)
sbuild_configure_batch_var_name_debug_release_string_lower_get(var_name_debrel_string_lower)
set(sbuild_configure_batch_debug_flag_content
set build_config=%1
echo \%0: build config: %build_config%\
if \%build_config%\ == \Release\ goto cfg_release
if \%build_config%\ == \Debug\ goto cfg_debug
if \%build_config%\ == \RelWithDebInfo\ goto cfg_release
if \%build_config%\ == \MinSizeRel\ goto cfg_release
echo \Unknown build configuration (%build_config%), please add support!\
rem fall-through to default Release setting (default should always be
non-debug! don't leak debug symbols...)
rem Provide several very different variables, to satisfy any and all potential
flag requirements
rem of various build environments
:cfg_release
set ${var_name_debug_yes_no}=no
set cfg_build_debug_enabled_int=0
set cfg_build_release_yes_no=yes
set cfg_build_release_enabled_int=1
set ${var_name_debrel_string_lower}=release
goto cfg_build_flags_done
:cfg_debug
set ${var_name_debug_yes_no}=yes
set cfg_build_debug_enabled_int=1
set cfg_build_release_yes_no=no
set cfg_build_release_enabled_int=0
set ${var_name_debrel_string_lower}=debug
goto cfg_build_flags_done
:cfg_build_flags_done
)
set(${_out_debug_flag_content} ${sbuild_configure_batch_debug_flag_content}
PARENT_SCOPE)
endfunction(sbuild_configure_batch_scriptlet_debug_flag_get
_out_debug_flag_content)
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Bug 13251 - failure extracting symbolic links from tarball on Windows
I'm running into this problem with building an ExternalProject via a tarball: CMake Error: Problem with archive_write_header(): Can't create '\' I vote for just writing the original file, so at least the build can continue. 2.8.10.2 completely stops the build now upon this error. Thanks, Kevin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Having trouble with component packaging
cmake/cpack 2.8.8 on redhat6
I'm trying to generate multiple tar.bz2 files for diffeent componenents and
I'm having some problems...running make package yields a single tarball
with all files. Relevant parts of CMakeLists.txt are below. Also tried
setting CMAKE_MONOLITHIC_INSTALL 0 to no effect.
# sample install commands
install(TARGETS MainExe RUNTIME DESTINATION bin CONFIGURATIONS Debug
COMPONENT DebugSDK)
install(TARGETS MainExe RUNTIME DESTINATION bin CONFIGURATIONS
Release;RelWithDebInfo;MinSizeRel COMPONENT ReleaseSDK)
install(DIRECTORY ${App_SOURCE_DIR}/../Release/DefaultSettings DESTINATION
. COMPONENT SDK)
#...
# cpack config
set(CPACK_GENERATOR TBZ2)
set(CPACK_TBZ2_COMPONENT_INSTALL ON)
set(CPACK_COMPONENTS_ALL SDK DebugSDK ReleaseSDK)
include(CPack)
--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
ret...@csh.rit.edu
http://www.csh.rit.edu/~retrev/
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Having trouble with component packaging
2012/12/7 Trevor Clarke ret...@csh.rit.edu:
cmake/cpack 2.8.8 on redhat6
I'm trying to generate multiple tar.bz2 files for diffeent componenents and
I'm having some problems...running make package yields a single tarball
with all files. Relevant parts of CMakeLists.txt are below. Also tried
setting CMAKE_MONOLITHIC_INSTALL 0 to no effect.
# sample install commands
install(TARGETS MainExe RUNTIME DESTINATION bin CONFIGURATIONS Debug
COMPONENT DebugSDK)
install(TARGETS MainExe RUNTIME DESTINATION bin CONFIGURATIONS
Release;RelWithDebInfo;MinSizeRel COMPONENT ReleaseSDK)
install(DIRECTORY ${App_SOURCE_DIR}/../Release/DefaultSettings DESTINATION .
COMPONENT SDK)
#...
# cpack config
set(CPACK_GENERATOR TBZ2)
set(CPACK_TBZ2_COMPONENT_INSTALL ON)
This one does not work,
TBZ2 belongs to ARCHIVE generator family (ZIP, TZ, TGZ, TBZ2)
thus you should use:
set(CPACK_ARCHIVE_COMPONENT_INSTALL ON)
if you want to have component packaging for TBZ2 and monolithic for ZIP
you'll have to use a CPACK_PROJECT_CONFIG_FILE in order
to set CPACK_ARCHIVE_COMPONENT_INSTALL at CPack-time depending
on the active CPack generator.
set(CPACK_COMPONENTS_ALL SDK DebugSDK ReleaseSDK)
include(CPack)
--
Trevor R.H. Clarke
Computer Science House
Rochester Institute of Technology
ret...@csh.rit.edu
http://www.csh.rit.edu/~retrev/
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPACK variable
2012/12/6 Stephen Rasku cm...@srasku.net: I am using cmake/cpack 2.8.9. We have cmake wrapped in Makefile. CMAKE and CPACK are defined in the Makefile as the full path to the respective executables. Cmake is expanding the cmake definition to the full path but cpack doesn't include the full path. This is the relevant section of CMakeFiles/rpm.dir/build.make. As you can see, cmake includes the full path but cpack does not. CMakeFiles/rpm: cpack /tools/swdev/packages/cmake/cmake-2.8.9/bin/cmake -E rename myPackage-devel.rpm myPackage-devel-1.0-3.i586-linux.rpm /tools/swdev/packages/cmake/cmake-2.8.9/bin/cmake -E rename myPackage-release.rpm myPackage-1.0-3.i586-linux.rpm Could you show us the relevant bits of your CMakeLists.txt which generate this? Could you try to: cd /path/to/builddir grep cpack CMakeCache.txt and give us the result please. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug 13251 - failure extracting symbolic links from tarball on Windows
Maybe as a workaround for now, you could construct the tarball you want manually... one that avoids these errors until this is fixed. On Fri, Dec 7, 2012 at 9:21 AM, Kevin Burge kevin.bu...@systemware.comwrote: I'm running into this problem with building an ExternalProject via a tarball: CMake Error: Problem with archive_write_header(): Can't create '\' I vote for just writing the original file, so at least the build can continue. 2.8.10.2 completely stops the build now upon this error. Thanks, Kevin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug 13251 - failure extracting symbolic links from tarball on Windows
Already done. It's the only way I can build. Of course, this means maintaining two sets of settings for the ExternalProject: one filename/md5sum for Unix, and one for Windows. Thanks for the suggestion. At Fri, 7 Dec 2012 11:16:35 -0500, David Cole wrote: Maybe as a workaround for now, you could construct the tarball you want manually... one that avoids these errors until this is fixed. On Fri, Dec 7, 2012 at 9:21 AM, Kevin Burge kevin.bu...@systemware.comwrote: I'm running into this problem with building an ExternalProject via a tarball: CMake Error: Problem with archive_write_header(): Can't create '\' I vote for just writing the original file, so at least the build can continue. 2.8.10.2 completely stops the build now upon this error. Thanks, Kevin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] problem with shortcut CPACK/NSIS
Dear all,
I know that this issue has been raised several times but all the
solution I tried failed up to now.
We have a Fortran 90 project for which we would like to create a NSIS
installer using CPACK. When installing the software
we would like:
- the PATH to be updated with the installation path
- to set another environment variable called SXTALSOFTSUITE
- create desktop and SMP shortcuts
All the trials we did up to now to create the SXTALSOFTSUITE failed even
when using the command:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS WriteRegStr HKCU 'Environment'
'SXTALSOFTSUITE' '$INSTDIR')
All the trials we did to update the path failed even when using:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS Push 'PATH'
Push 'A'
Push 'HKCU'
Push '$INSTDIRbin'
Call EnvVarUpdate
Pop '$0' )
However, the installation process by itself worked as all the files are
present in the installation directory. I have all the rights on my
machine so it may be not a permission problem. This drives me crazy.
You will find enclosed my CPACK files. If one of you could find what is
wrong with it it would be great.
thanks in advance
Eric
include (InstallRequiredSystemLibraries)
# General CPACK options
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VENDOR Eric Pellegrini - Institut Laue Langevin)
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
# NSIS section
if(CPACK_GENERATOR MATCHES NSIS)
# Create the desktop link
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS CreateShortCut
'$DESKTOPsxtalsoft.lnk' '$INSTDIRbintoolbar.exe' )
# Create the SXTALSOFTSUITE environment variable.
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS WriteRegStr HKCU 'Environment'
'SXTALSOFTSUITE' '$INSTDIR' )
# Update the PATH at installation.
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS Push 'PATH'
Push 'A'
Push 'HKCU'
Push '$INSTDIRbin'
Call EnvVarUpdate
Pop '$0' )
# Update the PATH at uninstallation.
set( CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS Push 'PATH'
Push 'R'
Push 'HKCU'
Push '$INSTDIRbin'
Call un.EnvVarUpdate
Pop '$0' )
# Delete the SXTALSOFTSUITE env variable at uninstallation.
DeleteRegValue HKCU 'Environment' 'SXTALSOFTSUITE'
# Delete the Desktop link at uninstallation.
Delete '$DESKTOPsxtalsoft.lnk' )
# The icon to start the application.
set(CPACK_NSIS_MUI_ICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcsxtalsoft.ico)
# The icon to uninstall the application.
set(CPACK_NSIS_MUI_UNIICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcuninstall_sxtalsoft.ico)
# The icon that appears in top of the installer dialog.
set(CPACK_PACKAGE_ICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcsxtalsoft_64.bmp)
# Add a link to the application website in the startup menu.
set(CPACK_NSIS_MENU_LINKS http://forge.ill.eu/projects/sxtalsoft;
Homepage for ${PROJECT_NAME})
# The file that will be displayed in the LICENSE section of the installer.
set(CPACK_RESOURCE_FILE_LICENSE ${sxtalsoft_SOURCE_DIR}LICENSE.txt)
# Set the icon for the application in the Add/Remove programs section.
set(CPACK_NSIS_INSTALLED_ICON_NAME bintoolbar.exe)
# The mail address for the maintainer of the application in the Add/Remove
programs section
set(CPACK_NSIS_CONTACT pellegr...@ill.eu)
# The url of the application in the Add/Remove programs section
set(CPACK_NSIS_URL_INFO_ABOUT http://forge.ill.eu/projects/sxtalsoft)
endif()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_EXECUTABLES toolbar ${PROJECT_NAME})
include(CPack)--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Having trouble with component packaging
That worked great! Thanks. On Fri, Dec 7, 2012 at 10:51 AM, Eric Noulard eric.noul...@gmail.comwrote: thus you should use: set(CPACK_ARCHIVE_COMPONENT_INSTALL ON) -- Trevor R.H. Clarke Computer Science House Rochester Institute of Technology ret...@csh.rit.edu http://www.csh.rit.edu/~retrev/ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Question on ExternalProject_Add and different dependency directives
Hi,
I love the ExternalProject_Add module and use it extensively in an
open-source build system I'm developing for our apps:
http://github.com/janelia-flyem/buildemhttps://github.com/janelia-flyem/buildem
The idea is to make a build environment from source, using cached tarballs,
and allow different version dependency graphs as commits in a git
repository of all build modules. I don't use FindPackage because we want
to know exactly how dependencies are built and modify parameters for some
of them. Also, just about everything above the language compiler level
gets built into one build prefix directory. The goal is to run at most two
cmake..; make... commands and have the system completely download and
build all necessary components from archived source.
In looking through the CMake message boards, I think I understand that
external projects aren't real targets but can still be used as
dependencies. As long as I use the DEPENDS in ExternalProject_Add(), the
dependencies seem to work as expected. However, I've run into an issue
where I'm using add_dependencies(EP1) where EP1 is an external project and
it's being rebuilt regardless of whether it was built already.
So I was hoping to get clarification on the different ways of specifying
dependencies and what happens after those statements.
DEPENDS in ExternalProject_Add lets you specify other external project
targets. The dependencies only get downloaded and built once. Question:
how does ExternalProject_Add determine when an external project needs to go
through its stages again? I read that git repo external projects are
always pulled unless you explicitly use an empty UPDATE_COMMAND.
If two different CMakeLists.txt include the same cmake file with a fixed
ExternalProject_Add's PREFIX directory, could there be some thrashing going
on?
add_dependencies(myexe EP1 EP2...) seems to work efficiently for most of my
modules (i.e, doesn't try to download, configure, etc, if it's done so
already), but for some more complicated ones, the external projects and its
dependencies always get rebuilt. I'm assuming there's something in my
modules that forces rebuilding of an external project even if its built.
In the suspect CMakeLists.txt for external project EP1 that I own, I have
a number of commands of the form:
project(EP1)
add_library(EP1 ${SOURCES})
add_dependencies(EP1 ep3 ep4)
add_custom_command(TARGET EP1
DEPENDS EP2 EP3
COMMAND dostuff)
add_custom_command(OUTPUT some_constants.h ${more_autogen_include_files}
DEPENDS thrift_EP
COMMAND generate_includes)
add_executable(foo foo.cpp)
target_link_libraries(foo EP1 ${foolibs})
set_source_files_properties(somestuff.cpp
PROPERTIES OBJECT_DEPENDS ${generated_file_dir}/some_constants.h)
I think there's either a deficiency in my understanding and/or one of the
above is forcing rebuilds. Any help would be appreciated in figuring out
where I'm going wrong.
Thanks,
Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode build attribute
How do I set a build attribute GCC_INPUT_FILE_TYPE for an xcode target. Ive tried set and add_definition but it always shows as according yo file type once the project is generated. Sent from my iPhone -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Static and DLL builds in single solution
Hi, I am quite new to CMake so forgive me if this has already been answered. My current build has a solution with several configurations, (debug, debugDLL, release, releaseDLL, etc.). I was able to add the custom configuration types to the generated VS solution but I am not sure how to tell CMake to generate a SHARED target type for only the dll configurations and a STATIC target type for the static configurations. Any help would be much appreciated. -Matt --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1243-gb0e04b3
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 b0e04b33e8e46e20dbbd04c4fc6b378717e6f904 (commit)
via f3953103f6f91d5bf1359f1eb0162ad26a1ab2dc (commit)
from d02456cb18822f74e2c67e7e080ffdff486e815b (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=b0e04b33e8e46e20dbbd04c4fc6b378717e6f904
commit b0e04b33e8e46e20dbbd04c4fc6b378717e6f904
Merge: d02456c f395310
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 09:53:52 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Dec 7 09:53:52 2012 -0500
Merge topic 'skip-variable-re-expansion' into next
f395310 Rename CMP0021 to CMP0019 and drop reserved spots in between
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3953103f6f91d5bf1359f1eb0162ad26a1ab2dc
commit f3953103f6f91d5bf1359f1eb0162ad26a1ab2dc
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 09:49:15 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Dec 7 09:50:19 2012 -0500
Rename CMP0021 to CMP0019 and drop reserved spots in between
The other policies under development using CMP0019 and CMP0020 will be
renumbered and added later. They may not be in 2.8.11 so it is simplest
to avoid confusion by not skipping any policy numbers.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 2552689..d943c45 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -814,7 +814,7 @@ bool cmMakefile::NeedBackwardsCompatibility(unsigned int
major,
void cmMakefile::FinalPass()
{
// do all the variable expansions here
- this-ExpandVariablesCMP0021();
+ this-ExpandVariablesCMP0019();
// give all the commands a chance to do something
// after the file has been parsed before generation
@@ -2122,15 +2122,15 @@ void cmMakefile::AddExtraDirectory(const char* dir)
this-AuxSourceDirectories.push_back(dir);
}
-static bool mightExpandVariablesCMP0021(const char* s)
+static bool mightExpandVariablesCMP0019(const char* s)
{
return s *s strstr(s,${) strchr(s,'}');
}
-void cmMakefile::ExpandVariablesCMP0021()
+void cmMakefile::ExpandVariablesCMP0019()
{
// Drop this ancient compatibility behavior with a policy.
- cmPolicies::PolicyStatus pol = this-GetPolicyStatus(cmPolicies::CMP0021);
+ cmPolicies::PolicyStatus pol = this-GetPolicyStatus(cmPolicies::CMP0019);
if(pol != cmPolicies::OLD pol != cmPolicies::WARN)
{
return;
@@ -2138,7 +2138,7 @@ void cmMakefile::ExpandVariablesCMP0021()
cmOStringStream w;
const char *includeDirs = this-GetProperty(INCLUDE_DIRECTORIES);
- if(mightExpandVariablesCMP0021(includeDirs))
+ if(mightExpandVariablesCMP0019(includeDirs))
{
std::string dirs = includeDirs;
this-ExpandVariablesInString(dirs, true, true);
@@ -2158,7 +2158,7 @@ void cmMakefile::ExpandVariablesCMP0021()
{
cmTarget t = l-second;
includeDirs = t.GetProperty(INCLUDE_DIRECTORIES);
-if(mightExpandVariablesCMP0021(includeDirs))
+if(mightExpandVariablesCMP0019(includeDirs))
{
std::string dirs = includeDirs;
this-ExpandVariablesInString(dirs, true, true);
@@ -2176,7 +2176,7 @@ void cmMakefile::ExpandVariablesCMP0021()
for(std::vectorstd::string::iterator d = this-LinkDirectories.begin();
d != this-LinkDirectories.end(); ++d)
{
-if(mightExpandVariablesCMP0021(d-c_str()))
+if(mightExpandVariablesCMP0019(d-c_str()))
{
std::string orig = *d;
this-ExpandVariablesInString(*d, true, true);
@@ -2193,7 +2193,7 @@ void cmMakefile::ExpandVariablesCMP0021()
this-LinkLibraries.begin();
l != this-LinkLibraries.end(); ++l)
{
-if(mightExpandVariablesCMP0021(l-first.c_str()))
+if(mightExpandVariablesCMP0019(l-first.c_str()))
{
std::string orig = l-first;
this-ExpandVariablesInString(l-first, true, true);
@@ -2210,7 +2210,7 @@ void cmMakefile::ExpandVariablesCMP0021()
if(!w.str().empty())
{
cmOStringStream m;
-m this-GetPolicies()-GetPolicyWarning(cmPolicies::CMP0021)
+m this-GetPolicies()-GetPolicyWarning(cmPolicies::CMP0019)
\n
The following variable evaluations were encountered:\n
w.str();
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 96a3d59..eff05d0 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -693,7 +693,7 @@ public:
/**
* Expand variables in the makefiles ivars such as link directories etc
*/
- void ExpandVariablesCMP0021();
+ void ExpandVariablesCMP0019();
/**
* Replace variables and #cmakedefine
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1248-g607d6b1
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 607d6b144c7c7a4622e1bbff1099aa0fc6a1e221 (commit)
via 11d6894279126d6789ebb4d14917a10829a4da1d (commit)
via a44480712cc9828c0cfc03db3108c220236d4da1 (commit)
from dcb4c478e1fb75c7b88e00c4fbf37275cf5052c4 (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=607d6b144c7c7a4622e1bbff1099aa0fc6a1e221
commit 607d6b144c7c7a4622e1bbff1099aa0fc6a1e221
Merge: dcb4c47 11d6894
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 14:04:24 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Dec 7 14:04:24 2012 -0500
Merge topic 'xcode-framework-paths' into next
11d6894 Makefile: Use modern link information for framework search paths
a444807 Xcode: Remove old incorrect framework path computation (#13397)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11d6894279126d6789ebb4d14917a10829a4da1d
commit 11d6894279126d6789ebb4d14917a10829a4da1d
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 13:27:52 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Dec 7 13:27:52 2012 -0500
Makefile: Use modern link information for framework search paths
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
diff --git a/Source/cmMakefileTargetGenerator.cxx
b/Source/cmMakefileTargetGenerator.cxx
index 2b89c79..9bf6b7d 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1550,10 +1550,10 @@ std::string
cmMakefileTargetGenerator::GetFrameworkFlags()
this-LocalGenerator-GetIncludeDirectories(includes,
this-GeneratorTarget,
C, config);
- std::vectorstd::string::iterator i;
// check all include directories for frameworks as this
// will already have added a -F for the framework
- for(i = includes.begin(); i != includes.end(); ++i)
+ for(std::vectorstd::string::iterator i = includes.begin();
+ i != includes.end(); ++i)
{
if(this-Target-NameResolvesToFramework(i-c_str()))
{
@@ -1565,17 +1565,21 @@ std::string
cmMakefileTargetGenerator::GetFrameworkFlags()
}
std::string flags;
- std::vectorstd::string frameworks = this-Target-GetFrameworks();
- for(i = frameworks.begin();
- i != frameworks.end(); ++i)
+ const char* cfg = this-LocalGenerator-ConfigurationName.c_str();
+ if(cmComputeLinkInformation* cli = this-Target-GetLinkInformation(cfg))
{
-if(emitted.insert(*i).second)
+std::vectorstd::string const frameworks = cli-GetFrameworkPaths();
+for(std::vectorstd::string::const_iterator i = frameworks.begin();
+i != frameworks.end(); ++i)
{
- flags += -F;
- flags += this-Convert(i-c_str(),
- cmLocalGenerator::START_OUTPUT,
- cmLocalGenerator::SHELL, true);
- flags += ;
+ if(emitted.insert(*i).second)
+{
+flags += -F;
+flags += this-Convert(i-c_str(),
+ cmLocalGenerator::START_OUTPUT,
+ cmLocalGenerator::SHELL, true);
+flags += ;
+}
}
}
return flags;
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index be20464..de3b23c 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2093,26 +2093,6 @@ bool cmTarget::NameResolvesToFramework(const
std::string libname)
}
//
-bool cmTarget::AddFramework(const std::string libname, LinkLibraryType)
-{
- if(this-NameResolvesToFramework(libname.c_str()))
-{
-std::string frameworkDir = libname;
-frameworkDir += /../;
-frameworkDir = cmSystemTools::CollapseFullPath(frameworkDir.c_str());
-std::vectorstd::string::iterator i =
- std::find(this-Frameworks.begin(),
-this-Frameworks.end(), frameworkDir);
-if(i == this-Frameworks.end())
- {
- this-Frameworks.push_back(frameworkDir);
- }
-return true;
-}
- return false;
-}
-
-//
void cmTarget::AddLinkLibrary(cmMakefile mf,
const char *target, const char* lib,
LinkLibraryType llt)
@@ -2122,7 +2102,6 @@ void cmTarget::AddLinkLibrary(cmMakefile
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1253-gbb48cb2
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 bb48cb26fb6660e915777fa6285d00c45e24ea55 (commit)
via f0d938549eead63fb86bec28c299a1bceacbdd6b (commit)
via 2bc22bdaacfc0f0f91c229685dc5dbadd0267601 (commit)
from 8475dd356cfaad9caaee49223b42582f94d9d8db (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=bb48cb26fb6660e915777fa6285d00c45e24ea55
commit bb48cb26fb6660e915777fa6285d00c45e24ea55
Merge: 8475dd3 f0d9385
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 15:49:30 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Dec 7 15:49:30 2012 -0500
Merge topic 'xcode-framework-paths' into next
f0d9385 Makefile: Use modern link information for framework search paths
2bc22bd Xcode: Add frameworks search paths from link dependeny closure
(#13397)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0d938549eead63fb86bec28c299a1bceacbdd6b
commit f0d938549eead63fb86bec28c299a1bceacbdd6b
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 7 13:27:52 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Dec 7 15:29:21 2012 -0500
Makefile: Use modern link information for framework search paths
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
diff --git a/Source/cmMakefileTargetGenerator.cxx
b/Source/cmMakefileTargetGenerator.cxx
index 2b89c79..9bf6b7d 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1550,10 +1550,10 @@ std::string
cmMakefileTargetGenerator::GetFrameworkFlags()
this-LocalGenerator-GetIncludeDirectories(includes,
this-GeneratorTarget,
C, config);
- std::vectorstd::string::iterator i;
// check all include directories for frameworks as this
// will already have added a -F for the framework
- for(i = includes.begin(); i != includes.end(); ++i)
+ for(std::vectorstd::string::iterator i = includes.begin();
+ i != includes.end(); ++i)
{
if(this-Target-NameResolvesToFramework(i-c_str()))
{
@@ -1565,17 +1565,21 @@ std::string
cmMakefileTargetGenerator::GetFrameworkFlags()
}
std::string flags;
- std::vectorstd::string frameworks = this-Target-GetFrameworks();
- for(i = frameworks.begin();
- i != frameworks.end(); ++i)
+ const char* cfg = this-LocalGenerator-ConfigurationName.c_str();
+ if(cmComputeLinkInformation* cli = this-Target-GetLinkInformation(cfg))
{
-if(emitted.insert(*i).second)
+std::vectorstd::string const frameworks = cli-GetFrameworkPaths();
+for(std::vectorstd::string::const_iterator i = frameworks.begin();
+i != frameworks.end(); ++i)
{
- flags += -F;
- flags += this-Convert(i-c_str(),
- cmLocalGenerator::START_OUTPUT,
- cmLocalGenerator::SHELL, true);
- flags += ;
+ if(emitted.insert(*i).second)
+{
+flags += -F;
+flags += this-Convert(i-c_str(),
+ cmLocalGenerator::START_OUTPUT,
+ cmLocalGenerator::SHELL, true);
+flags += ;
+}
}
}
return flags;
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index be20464..de3b23c 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2093,26 +2093,6 @@ bool cmTarget::NameResolvesToFramework(const
std::string libname)
}
//
-bool cmTarget::AddFramework(const std::string libname, LinkLibraryType)
-{
- if(this-NameResolvesToFramework(libname.c_str()))
-{
-std::string frameworkDir = libname;
-frameworkDir += /../;
-frameworkDir = cmSystemTools::CollapseFullPath(frameworkDir.c_str());
-std::vectorstd::string::iterator i =
- std::find(this-Frameworks.begin(),
-this-Frameworks.end(), frameworkDir);
-if(i == this-Frameworks.end())
- {
- this-Frameworks.push_back(frameworkDir);
- }
-return true;
-}
- return false;
-}
-
-//
void cmTarget::AddLinkLibrary(cmMakefile mf,
const char *target, const char* lib,
LinkLibraryType llt)
@@ -2122,7 +2102,6 @@ void
