[cmake-developers] [CMake 0013244]: components are append to Boost_LIBRARIES
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13244
==
Reported By:dam
Assigned To:
==
Project:CMake
Issue ID: 13244
Category: CMake
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2012-05-23 05:03 EDT
Last Modified: 2012-05-23 05:03 EDT
==
Summary:components are append to Boost_LIBRARIES
Description:
When using FindBoost in the same CMakeLists.txt and with different components,
the variable Boost_LIBRARIES contains the union of the components.
I think that Boost_LIBRARIES variable should be cleared when each time
find_package(Boost ...) is invoked, or perhaps the doc should mentioned this
behavior.
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(foo)
find_package(Boost COMPONENTS thread)
message(boost libs: ${Boost_LIBRARIES})
find_package(Boost COMPONENTS date_time)
message(\nboost libs: ${Boost_LIBRARIES})
# the result is:
# boost libs: /usr/lib/libboost_thread-mt.so
#
# boost libs: /usr/lib/libboost_thread-mt.so;/usr/lib/libboost_date_time-mt.so
# but I think it should be:
# boost libs: /usr/lib/libboost_date_time-mt.so
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-23 05:03 damNew 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] ninja failing CompileCommandOutput
Stephen Kelly wrote: Bill Hoffman wrote: CompileCommandOutput is failing with spaces in the path and ninja: http://open.cdash.org/testDetails.php?test=146442000build=2285894 Seems to be this commit: http://open.cdash.org/viewUpdate.php?buildid=2285734 Any ideas what is wrong? Oops, sorry I checked the dashboard, but I didn't see that failure last week. The problem is the space in one of the dirs in the source path. The Makefile generator seems to quote it: command: /usr/lib/icecc/bin/c++-I\/home/stephen/dev/src/one two/cmake/Tests/CompileCommandOutput/../../Source\-o CMakeFiles/CompileCommandOutput.dir/compile_command_output.cxx.o -c \/home/stephen/dev/src/one two/cmake/Tests/CompileCommandOutput/compile_command_output.cxx\, But the Ninja one doesn't: command: /usr/bin/c++-I\/home/stephen/dev/src/one two/cmake/Tests/CompileCommandOutput/../../Source\-o CMakeFiles/CompileCommandOutput.dir/compile_command_output.cxx.o -c /home/stephen/dev/src/one two/cmake/Tests/CompileCommandOutput/compile_command_output.cxx, I looked through the code, and didn't see what needs to be changed or where it gets quoted in the Makefile codepath. I'll have a closer look tomorrow. I've done this now. 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
[cmake-developers] [CMake 0013245]: FindQt4.cmake doesn't work on Windows 8
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13245 == Reported By:Stephen Kelly Assigned To:Clinton Stimpson == Project:CMake Issue ID: 13245 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 2012-05-23 14:23 EDT Last Modified: 2012-05-23 14:23 EDT == Summary:FindQt4.cmake doesn't work on Windows 8 Description: The output of qmake --version can contain a message which confuses FindQt4.cmake when run on Windows 8: qWarning(Qt: Untested Windows version %d.%d detected!, osver.dwMajorVersion, osver.dwMinorVersion); This may or may not be fixable in Qt: http://thread.gmane.org/gmane.comp.lib.qt.devel/4087 However, this issue most likely exists with all existing versions of Qt 4 anyway, so it may be worth working around by detecting and ignoring a line with that message in the output. == Issue History Date ModifiedUsername FieldChange == 2012-05-23 14:23 Stephen Kelly New Issue 2012-05-23 14:23 Stephen Kelly Status new = assigned 2012-05-23 14:23 Stephen Kelly Assigned To = Clinton Stimpson == -- 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] Making the default install component name configurable
On Tuesday 22 May 2012, Alexander Neundorf wrote: On Monday 14 May 2012, Alexander Neundorf wrote: On Monday 14 May 2012, Brad King wrote: On 5/13/2012 2:15 PM, Alexander Neundorf wrote: the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in Unspecified, so this is still the default. I'd rather the name be CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to keep the CMAKE_INSTALL_ prefix for variables affecting installation (along with CMAKE_INSTALL_PREFIX). Done, updated branch pushed. I've merged it into next now. Could this failure be caused by my commit ? http://open.cdash.org/testDetails.php?test=147001711build=2299302 The default behaviour should not have changed. Alex -- 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] find_library search orders with CMAKE_PREFIX_PATH CMAKE_FIND_ROOT_PATH
2012/5/23 Nicolas Tisserand n...@manctl.com: Hi all, I am currently building a collection of inter-dependent libraries and tools, mostly cmake-built, all installed to a common staging directory. I therefore need CMake find_library find_package commands to search in the staging directory first, before inspecting the system. Here's my problem: I can't get any combination of CMAKE_PREFIX_PATH or CMAKE_FIND_ROOT_PATH_MODE_* (in BOTH/NEVER/ONLY modes) to do this correctly, when find_library is given multiple names for the library. I'm not sure I understand, doesn't the -DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY case gives you want you want: == Looking for: png;png14 == Found: /Users/nt/Hacks/cmake-find-png/stage/lib/libpng14.a == Looking for: png14;png == Found: /Users/nt/Hacks/cmake-find-png/stage/lib/libpng14.a -- Configuring done -- Generating done -- Build files have been written to: /Users/nt/Hacks/cmake-find-png/build-ROOT_PATH_ONLY It only works using CMAKE_PREFIX_PATH, or CMAKE_FIND_ROOT_PATH CMAKE_FIND_ROOT_PATH_MODE=BOTH, provided that the name of the library present in the stage directory is the *first* of the library names list given to find_library. It seems like the search order in such cases is as follows (in pseudo-code): for each name in names for dir in stage, system if library_found(dir, name) return dir, name end end end This is the case (at least for find_library) if you look at Source/cmFindLibraryCommand.cxx std::string cmFindLibraryCommand::FindNormalLibrary() My use case would require the inner and outer loops to be swapped. This looks like a reasonable request to me but I can't imagine a way to support that without adding some option like PATH_FIRST to find_library. Again could you explain why the -DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY does not work for you? -- 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] Why is Ninja generator disabled by default?
Hi, On Tue, May 22, 2012 at 10:33:06AM -0400, cmake-requ...@cmake.org wrote: Date: Tue, 22 May 2012 06:35:35 -0500 From: Richard Wackerbarth rich...@nfsnet.org One of the differences that shows up in the dashboard is that there is a compile test which passes with normal Unix file paths, but fails when there is a space in one of the directory names. Perhaps we need to add an explicit test for everyone, ninja or otherwise, to test that compiles work with spaces in the path. I have a feeling that we may find additional failures. With yesterday's CMake next and an old Ninja (commit 1b471c1c4251dc05c2d5b71dd5d1d335c7827a9b Dec 2011), on a temporarily reactivated (Ninja did hit issues) whitespace test target within my build environment it complained with ninja: error: loading 'build.ninja': line 305, col 1: expected variable after $ due to Ninja generator converting Script Engine into Script$ Engine and old Ninja having issues with that syntax. With a current Ninja (git://github.com/martine/ninja.git master), the same generated build.ninja content now is accepted, and so far I haven't detected more whitespace issues here. So it's at least *better* than it used to be, but there might be hidden niceties lurking (and this is what the dashboard test result likely hints at). Andreas Mohr -- 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] cdash hiding dashboards
Yngve Levinsen yngve.levinsen@... writes: Dear all, I think I've managed to trigger the problem. I had recreated the projects and just now I changed the timezone on my computer. By accident it had been reset to Canada/Something, and I changed it back to Europe/Zurich again. After a computer restart the projects I host are again only showing the Coverage and Dynamic Analysis. So, to trigger bug: - Register a project on the server - Change timezone on server (typically /etc/rc.conf or similar on Linux machines) - Restart server Could anyone confirm this? Is it expected? Cheers, Yngve I ran into much the same problem, and after digging around in the source and in the mysql dump, it seems that CDash uses some magic timestamps (in particular, '1980-01-01 00:00:00' - see e.g the big $sql = ... query in index.php) and in the mysql database, these timestamps had been offset by my timezone change (so they were, in my case, 1979-12-31 21:00:00). This caused this main sql query to return no results. Much the same thing happens in the $groups = ... query in manageBuildGroup.php, so no current groups were listed. I dumped the cdash database, ran sed -i s/'1979-12-31 21:00:00'/'1980-01-01 00:00:00'/g cdash-dump.sql dropped and re-created the cdash database, and re-imported from cdash- dump.sql and everything was fine afterwards *but I don't recommend doing this with important data unless you know what you're doing, and getting the blessing of the cdash guys!* ;) Hope this helps, Simon -- 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] Overriding the toplevel directory name in a TGZ package?
The CPack tool provides a variable CMAKE_INCLUDE_TOPLEVEL_DIRECTORY option to control whether to set a toplevel directory in (say) a tar.gz archive, but so far I have not been able to figure out if there is a way to change this directory name to something not directly based on the file name. Trying to override CPACK_TOPLEVEL_DIRECTORY doesn't seem to work. Is there any way to get a tar.gz archive named (say) NEW_PROJECT-3.1.1.tar.gz that unpacks into a toplevel directory simply called PROJECT? Thanks, CY -- 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] Overriding the toplevel directory name in a TGZ package?
2012/5/23 Clifford Yapp cliffy...@gmail.com: The CPack tool provides a variable CMAKE_INCLUDE_TOPLEVEL_DIRECTORY option to control whether to set a toplevel directory in (say) a tar.gz archive, but so far I have not been able to figure out if there is a way to change this directory name to something not directly based on the file name. Trying to override CPACK_TOPLEVEL_DIRECTORY doesn't seem to work. CPACK_TOPLEVEL_DIRECTORY is internal to CPack thus Read-Only. Is there any way to get a tar.gz archive named (say) NEW_PROJECT-3.1.1.tar.gz that unpacks into a toplevel directory simply called PROJECT? Theoretically yes, using the variable: CPACK_PACKAGE_INSTALL_DIRECTORY This works with NSIS, but not with archive generator: There are 2 bugs pending for that: http://public.kitware.com/Bug/view.php?id=12606 http://public.kitware.com/Bug/view.php?id=13019 Woud you be willing to resume the work of the patch proposed in (see my comments too): http://public.kitware.com/Bug/view.php?id=12606 -- 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
[CMake] CMake for many interdependent libraries/executables
We currently have a fair number of libraries, executables and external
dependencies with fairly complicated dependencies. As a simplified example,
consider the following diagram where dependencies flow from top to bottom (i.e.
higher depends on lower).
exe1 exe2
| | \ /| |
| | \ / | |
| | \ / | |
| |\ / | |
| | \libd| |
| | \ | \| |
| | \ | \ | |
| | | |\ | |
| | | | \ | |
| libc| |libb |
| \ | | / | |
| \ | | /| |
| \ | | / | |
|\| |/ | |
| liba | |
|/ | |
| /| |
\ / | |
\ / | |
ext1 ext2
We don't modify external dependencies, but we do need to check them out and
build them before building a library or executable that depends on them.
Sometimes a developer will be working in a single library or executable.
Sometimes he will be working in multiple libraries and/or executables. You can
imagine that for a new developer it becomes very complicated to know which
libraries and executables need to be checked out and in which order they need
to be built in order to satisfy all the dependencies. Even established
developers that have all the necessary dependencies checked out and modify a
library have trouble knowing which libraries need to be rebuilt, and in what
order, for the change to propagate up to an executable.
In my ideal world, given that we can't change the dependency graph, I would
have a build system set up so that if I wanted to work on libb, I could simply
check it out and build it and it would automatically check out and build liba,
ext1, and ext2. Then if I made changes to liba, building libb would notice the
change in liba and trigger that build first. If I then decided that I needed
to work on exe2 I could check it out and build it and it would checkout and
build libd but use the existing libb, liba, ext1, and ext2 (triggering builds
as necessary if they are changed). To further complicate the situation, we
need to build on both Linux and Windows. So far we have been manually
maintaining makefiles on Linux and Visual Studio projects on Windows.
Phrased another way, I would like our build system to be able to:
1) Manage makefiles and Visual Studio solution/project files for us.
2) For a given library/executable, checkout and build missing dependencies.
3) For a given library/executable, build dependencies that have changed.
4) For a given executable, relink with changed dependent libraries (i.e. I
change libb and build it and then build exe2, which relinks with libb).
5) When building a given library/executable for the first time, use existing
dependencies within a given workspace (directory structure).
I have been investigation alternatives to our current system and CMake so far
seems to be the most promising. I have never used CMake before, however, so I
am not entirely sure that I can make it match my ideal world, though I think it
can. My current thoughts on how to accomplish this follow.
I know that CMake can handily manage #1.
I think that, given a directory structure similar to the following and setting
{TMP|STAMP|SOURCE|BINARY}_DIR appropriately, the ExternalProject module can
handle #2, #3 and #5.
workspace-folder
src
exe2
ext1
ext2
liba
libb
libd
build
exe2
ext1
ext2
liba
libb
libd
stamp
exe2
ext1
ext2
liba
libb
libd
tmp
exe2
ext1
ext2
liba
libb
libd
I think that a add_library(x UNKOWN IMPORTED) and set_property(TARGET x
PROPERTY IMPORTED_LOCATION y) combination can handle #4.
Does this seem reasonable? Is there a better way of doing it? Would
maintaining the ExternalProject superbuild CMakeLists.txt files separately
from the regular CMakeLists.txt files be the recommended approach?
Thanks in advance for any help.
--
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] CMake for many interdependent libraries/executables
On Wed, May 23, 2012 at 9:52 AM, Wiser, Tyson twi...@logostech.net wrote: We don't modify external dependencies, but we do need to check them out and build them before building a library or executable that depends on them. Sometimes a developer will be working in a single library or executable. Sometimes he will be working in multiple libraries and/or executables. You can imagine that for a new developer it becomes very complicated to know which libraries and executables need to be checked out and in which order they need to be built in order to satisfy all the dependencies. Even established developers that have all the necessary dependencies checked out and modify a library have trouble knowing which libraries need to be rebuilt, and in what order, for the change to propagate up to an executable. How impractical would it be to always check out and build everything? How close is an incremental build over the whole tree to fast enough? - Dan -- 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] find_library search orders with CMAKE_PREFIX_PATH CMAKE_FIND_ROOT_PATH
On Wed, May 23, 2012 at 1:01 AM, Eric Noulard eric.noul...@gmail.com wrote:
I'm not sure I understand, doesn't the
-DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY
case gives you want you want:
Yes, I forgot to clarify that point. It does not work for me either,
because it completely discards all system libraries (like libm.dylib
or CoreFoundation.framework on the mac, for instance), which makes it
difficult to build anything useful without copying or symbolic-linking
all the system libraries in the stage/lib directory.
What I would need is simply to have the custom-built libraries take
precedence over their potential system-wide versions.
This is the case (at least for find_library) if you look at
Source/cmFindLibraryCommand.cxx
std::string cmFindLibraryCommand::FindNormalLibrary()
Thanks for the tip :-)
My use case would require the inner and outer loops to be swapped.
This looks like a reasonable request to me but I can't imagine a way
to support that without adding some option like PATH_FIRST to
find_library.
This would be nice but would require to edit the find_library calls in
the build system of all the custom-built libraries, which is not very
desirable, because I do not maintain them.
Could something like
-DCMAKE_FIND_ROOT_PATH_MODE_{PROGRAM,INCLUDE,LIBRARY}:STRING=FIRST be
envisioned instead? That way, I could trigger the correct build
through command line switches, without intrusive editions.
Again could you explain why the
-DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY
does not work for you?
Yeah, sure. As stated above, it restricts the set of libraries
available through find_library to the exact contents of the stage
directory, thus completely discarding some required standard
libraries.
--
Nicolas
--
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] CMake for many interdependent libraries/executables
We don't modify external dependencies, but we do need to check them out and build them before building a library or executable that depends on them. Sometimes a developer will be working in a single library or executable. Sometimes he will be working in multiple libraries and/or executables. You can imagine that for a new developer it becomes very complicated to know which libraries and executables need to be checked out and in which order they need to be built in order to satisfy all the dependencies. Even established developers that have all the necessary dependencies checked out and modify a library have trouble knowing which libraries need to be rebuilt, and in what order, for the change to propagate up to an executable. How impractical would it be to always check out and build everything? How close is an incremental build over the whole tree to fast enough? - Dan Some of our external dependencies (e.g. boost) are quite large and can take a very long time to build. We also have several different customers that each get a different set of executables, but those executables all make use of some subset of the same libraries. Occasionally we need to switch from working for one customer to another and it is nice to not have separate workspaces (and thus avoid duplicate code and data files on disk). So the short answer is it is not very practical to always check out and build everything. It's hard to say how fast an incremental build is over the whole tree. It has always been a manual process. In my example, if I changed liba I would have to build it, build libb, build libd, and then build exe2. Each of the individual builds were usually a couple of seconds so I imagine that an incremental build over the whole tree would just be a few seconds per node on average (hopefully faster if nothing actually changed). I realized that I didn't explicitly mention this, but each library and executable has its own repository and is currently treated as its own project as far as the makefiles/VS solution files are concerned. I would like to keep it that way but be able to have the option of the superbuild for each project that would take care of the current project and all its dependencies. Each depender could thus call each of its dependees' superbuild. I think that would allow a developer to be able to work on a given library in isolation without needing to have all the projects that depend on it checked out, yet still allow another developer working on a different project that depends on that library to easily check it out and build it. -- 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] find_library search orders with CMAKE_PREFIX_PATH CMAKE_FIND_ROOT_PATH
Regarding the loop swapping you ask about in your original post:
I know we've discussed swapping those loops before on this list, quite to
exhaustion.
The bottom line is: we will not be changing those loops so as to preserve
existing behavior. If we do add code to swap those loops, then it would
have to be conditionally activated, only in response to people requesting
it by explicitly setting a variable (or some equivalent mechanism).
I don't know how far back this discussion was, but it's in the archives.
(If anybody can provide a pointer to the exact thread, that would be
great...)
HTH,
David
On Wed, May 23, 2012 at 2:22 PM, Nicolas Tisserand
nicolas.tisser...@gmail.com wrote:
On Wed, May 23, 2012 at 1:01 AM, Eric Noulard eric.noul...@gmail.com
wrote:
I'm not sure I understand, doesn't the
-DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY
case gives you want you want:
Yes, I forgot to clarify that point. It does not work for me either,
because it completely discards all system libraries (like libm.dylib
or CoreFoundation.framework on the mac, for instance), which makes it
difficult to build anything useful without copying or symbolic-linking
all the system libraries in the stage/lib directory.
What I would need is simply to have the custom-built libraries take
precedence over their potential system-wide versions.
This is the case (at least for find_library) if you look at
Source/cmFindLibraryCommand.cxx
std::string cmFindLibraryCommand::FindNormalLibrary()
Thanks for the tip :-)
My use case would require the inner and outer loops to be swapped.
This looks like a reasonable request to me but I can't imagine a way
to support that without adding some option like PATH_FIRST to
find_library.
This would be nice but would require to edit the find_library calls in
the build system of all the custom-built libraries, which is not very
desirable, because I do not maintain them.
Could something like
-DCMAKE_FIND_ROOT_PATH_MODE_{PROGRAM,INCLUDE,LIBRARY}:STRING=FIRST be
envisioned instead? That way, I could trigger the correct build
through command line switches, without intrusive editions.
Again could you explain why the
-DCMAKE_FIND_ROOT_PATH:PATH=/Users/nt/Hacks/cmake-find-png/stage
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING=ONLY
does not work for you?
Yeah, sure. As stated above, it restricts the set of libraries
available through find_library to the exact contents of the stage
directory, thus completely discarding some required standard
libraries.
--
Nicolas
--
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] Need to prepend compiler with static analysis tool
Hey all, I'm trying to integrate insure++ with my cmake workspace. The way insure works is that you prepend the compiler with the insure executable. For example /usr/bin/insure /usr/bin/g++ -o test test.cpp. I've tried to overrid CMAKE_CXX_COMPILER with these two executables, but it doesn't seem like CMAKE likes this way. I've also tried overriding CXX before running cmake with this. Can someone please tell me how to make this work? Seems like it should be simple enough, but I'm not finding the answer :-). Thanks! -JD -- View this message in context: http://cmake.3232098.n2.nabble.com/Need-to-prepend-compiler-with-static-analysis-tool-tp7574176.html Sent from the CMake mailing list archive at Nabble.com. -- 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] Need to prepend compiler with static analysis tool
On Wednesday 23 May 2012, jrosensw wrote: Hey all, I'm trying to integrate insure++ with my cmake workspace. The way insure works is that you prepend the compiler with the insure executable. For example /usr/bin/insure /usr/bin/g++ -o test test.cpp. I've tried to overrid CMAKE_CXX_COMPILER with these two executables, but it doesn't seem like CMAKE likes this way. I've also tried overriding CXX before running cmake with this. Can someone please tell me how to make this work? Seems like it should be simple enough, but I'm not finding the answer :-). Something like the following shoduld work: $ CXX=/usr/bin/insure /usr/bin/g++ cmake .. (on a fresh build tree) Alex -- 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] Need to prepend compiler with static analysis tool
Hi Alexander, I tried this already. However I'm not sure what a clean build tree means. Maybe thats my problems. All I did was this: CXX=path/insure path/g++ cmake . But when I compiled I did not see a change. How do I get my tree to a clean state? Other than running make clean which I did do. Thanks, JD -- View this message in context: http://cmake.3232098.n2.nabble.com/Need-to-prepend-compiler-with-static-analysis-tool-tp7574176p7574208.html Sent from the CMake mailing list archive at Nabble.com. -- 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] Need to prepend compiler with static analysis tool
On 5/23/2012 4:45 PM, jrosensw wrote: Hi Alexander, I tried this already. However I'm not sure what a clean build tree means. Maybe thats my problems. All I did was this: CXX=path/insurepath/g++ cmake . But when I compiled I did not see a change. How do I get my tree to a clean state? Other than running make clean which I did do. rm -rf CMakeCache* CMakeFiles* - Oliver -- 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] Clang + MinGW Linking Issue
Hi All, I've been trying out CMake for building C++ applications on Windows with Clang, using the MinGW headers/libraries. This works fine, except if I need to pull in non-default system libraries that are included with MinGW, such as libpsapi.a (psapi.lib for VS). For example, if I have the following CMakeLists.txt file: project(pstest1) add_executable(pstest1 pstest1.cpp) target_link_libraries(pstest1 psapi) This fails with a linker error: Linking CXX executable pstest1.exe c:\projects\cmake-2.8.8-win32-x86\bin\cmake.exe -E cmake_link_script CMakeFiles\pstest1.dir\link.txt --verbose=1 C:\projects\clang+llvm-3.1-i386-mingw32-EXPERIMENTAL\bin\clang++.exe CMakeFiles/pstest1.dir/pstest1.obj -o pst est1.exe *-lpsapi.lib* *c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lpsapi.lib* collect2: ld returned 1 exit status clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) mingw32-make[2]: *** [pstest1.exe] Error 1 mingw32-make[2]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make[1]: *** [CMakeFiles/pstest1.dir/all] Error 2 mingw32-make[1]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make: *** [all] Error 2 CMake seems to be using MSVC library naming conventions for Clang in MinGW mode, but also using the GCC-style -l flags for specifying libraries. If I replace target_link_libraries(pstest1 psapi) with target_link_libraries(pstest1 c:/MinGW/lib/libpsapi.a) then everything works as expected (I got -lpsapi on the link line). Interestingly, everything also works correctly if I use the default mingw32-gcc.exe compiler instead of clang.exe. So this seems to be a CMake issue where it detects Clang but does not know how to properly pass GCC-style linker flags to Clang. Any ideas? -- Thanks, Justin Holewinski -- 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] Need to prepend compiler with static analysis tool
Thanks Oliver! -- View this message in context: http://cmake.3232098.n2.nabble.com/Need-to-prepend-compiler-with-static-analysis-tool-tp7574176p7574256.html Sent from the CMake mailing list archive at Nabble.com. -- 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] Need to prepend compiler with static analysis tool
2012/5/23 Oliver Smith osm...@playnet.com: On 5/23/2012 4:45 PM, jrosensw wrote: Hi Alexander, I tried this already. However I'm not sure what a clean build tree means. Maybe thats my problems. All I did was this: CXX=path/insurepath/g++ cmake . But when I compiled I did not see a change. How do I get my tree to a clean state? Other than running make clean which I did do. rm -rf CMakeCache* CMakeFiles* and you should build out-of-source http://www.cmake.org/Wiki/CMake_FAQ#What_is_an_.22out-of-source.22_build.3F this makes the clean-up as easy as rm -rf build-tree -- 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] find_library search orders with CMAKE_PREFIX_PATH CMAKE_FIND_ROOT_PATH
On Wed, May 23, 2012 at 11:29 AM, David Cole david.c...@kitware.com wrote:
Regarding the loop swapping you ask about in your original post:
I know we've discussed swapping those loops before on this list, quite to
exhaustion.
I'm sorry to read that... now that I raised the topic again.
The bottom line is: we will not be changing those loops so as to preserve
existing behavior. If we do add code to swap those loops, then it would
have to be conditionally activated, only in response to people requesting
it by explicitly setting a variable (or some equivalent mechanism).
That sound perfectly fine to me. In fact, the fact that the CMake team is
doing a great job at not breaking existing build systems when shipping new
versions is one of the reasons why I use CMake.
I don't know how far back this discussion was, but it's in the archives.
(If anybody can provide a pointer to the exact thread, that would be
great...)
Was a consensus reached, back then?
I would very much like to see such an addition to CMake.
As proposed in my previous email, an additional FIRST value to the
CMAKE_FIND_ROOT_PATH_MODE_{PROGRAM,INCLUDE,LIBRARY} {ONLY,NEVER,BOTH} set
would perfectly fit the bill, in my case.
Would that be hard to do?
Would it be considered as a welcome addition?
Best,
Nicolas
--
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.8-2919-g8ee9ec4
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 8ee9ec40bb9d5dab474dbd4daa158da55ffd (commit) via f43066fe0cb7dcd0ce5e8304dd6d3895aeae5759 (commit) from 683f838337494cb13eafa5867ef46929efb1a5d5 (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=8ee9ec40bb9d5dab474dbd4daa158da55ffd commit 8ee9ec40bb9d5dab474dbd4daa158da55ffd Merge: 683f838 f43066f Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed May 23 12:10:37 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed May 23 12:10:37 2012 -0400 Merge topic 'Ninja-EXPORT_COMPILE_COMMANDS' into next f43066f Escape the source file to be compiled if required. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f43066fe0cb7dcd0ce5e8304dd6d3895aeae5759 commit f43066fe0cb7dcd0ce5e8304dd6d3895aeae5759 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed May 23 18:08:23 2012 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed May 23 18:08:23 2012 +0200 Escape the source file to be compiled if required. Whitespaces in paths can otherwise cause invalid command lines to be generated. diff --git a/Source/cmNinjaTargetGenerator.cxx b/Source/cmNinjaTargetGenerator.cxx index 7c58154..e419a4d 100644 --- a/Source/cmNinjaTargetGenerator.cxx +++ b/Source/cmNinjaTargetGenerator.cxx @@ -492,7 +492,10 @@ cmNinjaTargetGenerator cmLocalGenerator::RuleVariables compileObjectVars; std::string lang = language; compileObjectVars.Language = lang.c_str(); -compileObjectVars.Source = sourceFileName.c_str(); +std::string escapedSourceFileName = + this-LocalGenerator-ConvertToOutputFormat( +sourceFileName.c_str(), cmLocalGenerator::SHELL); +compileObjectVars.Source = escapedSourceFileName.c_str(); compileObjectVars.Object = objectFileName.c_str(); compileObjectVars.Flags = vars[FLAGS].c_str(); compileObjectVars.Defines = vars[DEFINES].c_str(); --- Summary of changes: Source/cmNinjaTargetGenerator.cxx |5 - 1 files changed, 4 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.8-2922-g5cd83e8
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 5cd83e87123fce024b449d01d7e40f6742e5b5d4 (commit)
via 14b213c0ceb9fb2882dc41574ebacaf0ef906fc1 (commit)
via 00ae36fdfffe39fb71cb54f81990b44be81d6833 (commit)
from 8ee9ec40bb9d5dab474dbd4daa158da55ffd (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=5cd83e87123fce024b449d01d7e40f6742e5b5d4
commit 5cd83e87123fce024b449d01d7e40f6742e5b5d4
Merge: 8ee9ec4 14b213c
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed May 23 14:51:01 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed May 23 14:51:01 2012 -0400
Merge topic 'HandleEmptySIZEOF_VOID_P' into next
14b213c add test for #13241: empty SIZEOF_VOIDP in
write_basic_package_version_file
00ae36f write_basic_package_version_file() now works with unset
CMAKE_SIZEOF_VOID_P
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14b213c0ceb9fb2882dc41574ebacaf0ef906fc1
commit 14b213c0ceb9fb2882dc41574ebacaf0ef906fc1
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed May 23 20:48:47 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed May 23 20:48:47 2012 +0200
add test for #13241: empty SIZEOF_VOIDP in write_basic_package_version_file
Alex
diff --git a/Tests/FindPackageTest/CMakeLists.txt
b/Tests/FindPackageTest/CMakeLists.txt
index 5862094..e85fb4d 100644
--- a/Tests/FindPackageTest/CMakeLists.txt
+++ b/Tests/FindPackageTest/CMakeLists.txt
@@ -363,10 +363,16 @@ endif()
#-
# Test write_basic_config_version_file().
+# also test that an empty CMAKE_SIZEOF_VOID_P is accepted:
+set(_CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
+set(CMAKE_SIZEOF_VOID_P )
+
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake
VERSION 1.2.3
COMPATIBILITY AnyNewerVersion)
+set(CMAKE_SIZEOF_VOID_P ${_CMAKE_SIZEOF_VOID_P})
+
set(PACKAGE_FIND_VERSION 2.3.4)
include(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake)
if(PACKAGE_VERSION_COMPATIBLE)
@@ -379,6 +385,10 @@ if(NOT PACKAGE_VERSION_COMPATIBLE)
message(SEND_ERROR Did not find Foo123 with version 1.2.3 (0.0.1 was
requested) !)
endif()
+if(PACKAGE_VERSION_UNSUITABLE)
+ message(SEND_ERROR PACKAGE_VERSION_UNSUITABLE set, but must not be !)
+endif()
+
set(PACKAGE_FIND_VERSION 1.0.0)
include(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake)
if(NOT PACKAGE_VERSION_COMPATIBLE)
@@ -405,6 +415,7 @@
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/Boo123ConfigVersion.
VERSION 1.2.3
COMPATIBILITY SameMajorVersion)
+unset(PACKAGE_VERSION_UNSUITABLE)
set(PACKAGE_VERSION_EXACT FALSE)
set(PACKAGE_FIND_VERSION 2.3.4)
set(PACKAGE_FIND_VERSION_MAJOR 2)
@@ -456,6 +467,7 @@
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/Bar123ConfigVersion
VERSION 1.2.3.17
COMPATIBILITY ExactVersion)
+unset(PACKAGE_VERSION_UNSUITABLE)
set(PACKAGE_VERSION_EXACT FALSE)
set(PACKAGE_FIND_VERSION 2.3.4)
include(${CMAKE_CURRENT_BINARY_DIR}/Bar123ConfigVersion.cmake)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00ae36fdfffe39fb71cb54f81990b44be81d6833
commit 00ae36fdfffe39fb71cb54f81990b44be81d6833
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed May 23 20:46:48 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed May 23 20:46:48 2012 +0200
write_basic_package_version_file() now works with unset CMAKE_SIZEOF_VOID_P
This fixes #13241.
If CMAKE_SIZEOF_VOID_P is not set, either in the installed or in the
using project, don't check for it.
Alex
diff --git a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
index cf53db8..9f7f03e 100644
--- a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
+++ b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
@@ -18,6 +18,11 @@ else()
endif()
endif()
+# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set,
ignore it:
+if(${CMAKE_SIZEOF_VOID_P} STREQUAL OR @CMAKE_SIZEOF_VOID_P@ STREQUAL
)
+ return()
+endif()
+
# check that the installed version has the same 32/64bit-ness as the one which
is currently searching:
if(NOT ${CMAKE_SIZEOF_VOID_P} STREQUAL @CMAKE_SIZEOF_VOID_P@)
math(EXPR installedBits @CMAKE_SIZEOF_VOID_P@ * 8)
diff --git
[Cmake-commits] CMake branch, master, updated. v2.8.8-199-g1e3dde2
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 1e3dde2ddb20457d6a5ca3399d3add46f37c2516 (commit) from 4df451131b7b4e44e12402fef94f4ad7207d17f0 (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=1e3dde2ddb20457d6a5ca3399d3add46f37c2516 commit 1e3dde2ddb20457d6a5ca3399d3add46f37c2516 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu May 24 00:01:04 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu May 24 00:01:04 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 3e13d7c..b02b3a8 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ SET(CMake_VERSION_MAJOR 2) SET(CMake_VERSION_MINOR 8) SET(CMake_VERSION_PATCH 8) -SET(CMake_VERSION_TWEAK 20120523) +SET(CMake_VERSION_TWEAK 20120524) #SET(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
