Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist
On 1/25/2012 1:50 AM, Michael Wild wrote:
So, to fix your code, use IMPORTED_LOCATION_NOCONFIG.
Actually just use LOCATION or LOCATION_${CONFIG} for some CONFIG:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION_CONFIG
They will tell you where to find the target file for any target,
including imported targets. The IMPORTED_... properties are really
meant for *setting* to tell CMake something, not for *getting*
information from CMake.
-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] Improving CPack Documentation (and may be others as well)
On 1/24/2012 5:50 PM, Eric Noulard wrote: cmake --help-module CPackComponent or any other (untouched module) cmake --help-module FindQt4 you'll see that the extra space are there as well. So yes there is too much space, but this is not due to my current proposal, it was there before. We can handle that separately. Agreed. Sorry, I forgot that this problem already existed. It was created by the original module documentation extractor. It inconsistently treats transitions from paragraph text to preformatted text and back, giving the latter extra blank lines. Now we can't fix it without changing the formatting of all the existing documentation. (Perhaps the markup can help with that later.) I won't be doing this now I'd rather agree on the new markup feature first. The markup feature looks fine to me. The markup syntax adds some information even for those reading the raw source. I don't know if others have an opinion though. -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] New module introduction
I have a question for the developers list since I'm (brand) new to this: Right now, the FindBLAS and FindLAPACK will not find Intel MKL that ships with versions of the compiler released since last year. We've written something that will make it work, but right now we only have it working on Linux with intel64 architecture. We don't have time right now to put in Windows support or 32bit support. And even if we could, we don't have any Windows or 32bit machines to test it on anyway. So should I push what I have and get it into the stream with the deficiencies documented since what is there will at least fix problems for many people? Should I leave it on the stage branch until either we or somebody else can help us with the remainder of it? I'll hold off on pushing anything until I know if pushing partial support is okay or not. Thanks, Tim - Original Message - From: Tim Gallagher tim.gallag...@gatech.edu To: cmake-developers@cmake.org Sent: Tuesday, January 24, 2012 9:10:43 PM Subject: [cmake-developers] New module introduction Hi, I've been on the users mailing list a few different times to submit patches for the FindBLAS and FindLAPACK modules and we found some more bugs with them. It was known awhile ago that they don't work for the new Intel MKL naming conventions (http://www.mail-archive.com/cmake@cmake.org/msg38606.html). We finally hit the point where we had to fix it. So, in order to do this correctly, there is an additional module that interfaces with a tool provided by Intel to generate the information needed to link. We've written this module and are polishing it now. We've also modified FindBLAS and FindLAPACK to use the new module and also fixed a few smaller bugs during this process. I would like to sign up as a module maintainer for this new module (and get push access to put it in the repository). I've done all the steps on the wiki for doing this except introducing the module (which is what I'm doing now!) and applying for git access (which I will do when I find out this email was what 'introduce the module' meant). If I need to send out the new module first for review or something, let me know and we'll do it as soon as it's finished. Thanks, Tim -- 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 -- 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 0012914]: GUI Idea : an open project button
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12914 == Reported By:Michael Broutin Assigned To: == Project:CMake Issue ID: 12914 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2012-01-25 13:08 EST Last Modified: 2012-01-25 13:08 EST == Summary:GUI Idea : an open project button Description: Here's a common workflow I have : open CMake GUI, configure, generate, then open windows file exporer, find the directory where I put the build files, double click on the project file... I have a feeling that it could be further streamlined simply by adding a open project button on CMake's GUI. Of course, you could argue that it's irrelevant in quite a few cases (when there's no IDE associated with the generated file, for example with gcc makefile), but the button could be displayed only when it's relevant for the selected generator. == Issue History Date ModifiedUsername FieldChange == 2012-01-25 13:08 Michael BroutinNew 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] Documented property IMPORTED_LOCATION does not exist
On 2012-01-25 08:14-0500 Brad King wrote:
On 1/25/2012 1:50 AM, Michael Wild wrote:
So, to fix your code, use IMPORTED_LOCATION_NOCONFIG.
Actually just use LOCATION or LOCATION_${CONFIG} for some CONFIG:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION_CONFIG
They will tell you where to find the target file for any target,
including imported targets. The IMPORTED_... properties are really
meant for *setting* to tell CMake something, not for *getting*
information from CMake.
That important distinction between IMPORTED_LOCATION and LOCATION
needs clarification in the documentation so even experienced CMake
users like me are not mislead.
For example, under PROPERTIES ON TARGETS, the IMPORTED_LOCATION
documentation uses the phrase this is a lot implying the property
exists (i.e., has been reliably set) for any given imported target.
Michael's original response to me said he used IMPORTED_LOCATION all
the time with no issues. So he apparently configures his software
builds in some way (is that because you always set CMAKE_BUILD_TYPE,
Michael?) to actually make the exported modules contain
IMPORTED_LOCATION, while for PLplot I just build it with no specified
CMAKE_BUILD_TYPE so only IMPORTED_LOCATION_NOCONFIG (but not
IMPORTED_LOCATION) is set in the exported modules.
Is that the real issue here? Should exporting a target automatically
set both IMPORTED_LOCATION_NOCONFIG _and_ IMPORTED_LOCATION for all
cases (e.g., when you haven't set CMAKE_BUILD_TYPE as in my particular
PLplot build)?
Of course, if I had read further in the documentation to LOCATION, it
is made clear there that is the READ-ONLY one that should be used for
most generality.
But I didn't read further since the IMPORTED_LOCATION section implied
that property would be set reliably for imported targets, and
certainly Michael's original response seemed to confirm that as well,
i.e., his experience seemed to be consistent with that documentation.
So it appear to me the choices are to set IMPORTED_LOCATION in export
modules reliably regardless of how CMAKE_BUILD_TYPE is set (or not
set) or to change the documentation of IMPORTED_LOCATION to indicate
it is not always reliably set for imported targets and urge the reader
to use LOCATION instead.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
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] Improving CPack Documentation (and may be others as well)
2012/1/25 Brad King brad.k...@kitware.com: On 1/24/2012 5:50 PM, Eric Noulard wrote: cmake --help-module CPackComponent or any other (untouched module) cmake --help-module FindQt4 you'll see that the extra space are there as well. So yes there is too much space, but this is not due to my current proposal, it was there before. We can handle that separately. Agreed. Sorry, I forgot that this problem already existed. It was created by the original module documentation extractor. It inconsistently treats transitions from paragraph text to preformatted text and back, giving the latter extra blank lines. Now we can't fix it without changing the formatting of all the existing documentation. (Perhaps the markup can help with that later.) I won't be doing this now I'd rather agree on the new markup feature first. The markup feature looks fine to me. The markup syntax adds some information even for those reading the raw source. Yes and I forgot to mention that it has a extra feature compared to the current module doc parser. It does look for markup on the **whole** file unlike current module doc parser which only parse the header (at the beginning of the file). So with my proposal you can perfectly document a script in the middle of the file or as usual just in front of the concerned macro/function/var. This may be easier for doc maintenance because the function/macro would be closer to its doc. This could be further used for user script that could be documented this way as well. My idea for user script doc support may be to add an extra cdoc command that would be dedicated to documentation of script files: a) cdoc --help-command-list yourscript.cmake b) cdoc --help-variable-list yourscript.cmake c) cdoc --help yourscript.cmake may spit out: a) the doc for macro/function in the concerned script b) the doc for variables c) all doc this command may have more versatile option to include or exclude (cmake/ctest/cpack) doc and/or add some path where to parse all *.cmake files etc An alternative would be to defined something like: CMAKE_USER_DOC_PATHS CPACK_USER_DOC_PATHS CTEST_USER_DOC_PATHS that could contain a list of user set PATHS containing *.cmake files and then cmake ---help-command-list would also load and parse all *.cmake files found in CMAKE_USER_DOC_PATHS. whatever the idea we should be able to share: - the markup for CMake/CTest/CPack **and** user scripts - the doc parser and formatter. I don't know if others have an opinion though. Opinion/feedback from other are more than welcome. The limitation I personnally see in such kind of markup is that it cannot be very much enhanced (cross-link, more text formatting like bold, italic, etc...) without breaking current doc parser. So if we accept to break backward compatible module doc parser we could easily add more advance markup. An intermediate option would be to trap to more advanced markup only in a new markup section. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist
On 1/25/2012 3:12 PM, Alan W. Irwin wrote: change the documentation of IMPORTED_LOCATION to indicate it is not always reliably set for imported targets and urge the reader to use LOCATION instead. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d20619f -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] Improving CPack Documentation (and may be others as well)
On 1/25/2012 3:20 PM, Eric Noulard wrote: So with my proposal you can perfectly document a script in the middle of the file or as usual just in front of the concerned macro/function/var. This may be easier for doc maintenance because the function/macro would be closer to its doc. Nice. My idea for user script doc support may be to add an extra cdoc command that would be dedicated to documentation of script files: I think cmake --doc is better than a new command tool in the PATH. An alternative would be to defined something like: CMAKE_USER_DOC_PATHS CPACK_USER_DOC_PATHS CTEST_USER_DOC_PATHS If a module does not come with CMake I'd rather ask the user to explicitly list the modules to be included in a documentation request on the command line. The limitation I personnally see in such kind of markup is that it cannot be very much enhanced (cross-link, more text formatting like bold, italic, etc...) without breaking current doc parser. I'd rather switch to a real documentation engine like asciidoc than implement all those markup capabilities. We'd need one that can handle literate programming for .cmake modules though. -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] Improving CPack Documentation (and may be others as well)
On Wednesday 25 January 2012, Eric Noulard wrote: 2012/1/25 Brad King brad.k...@kitware.com: On 1/24/2012 5:50 PM, Eric Noulard wrote: cmake --help-module CPackComponent or any other (untouched module) cmake --help-module FindQt4 you'll see that the extra space are there as well. So yes there is too much space, but this is not due to my current proposal, it was there before. We can handle that separately. Agreed. Sorry, I forgot that this problem already existed. It was created by the original module documentation extractor. It inconsistently treats transitions from paragraph text to preformatted text and back, giving the latter extra blank lines. Now we can't fix it without changing the formatting of all the existing documentation. (Perhaps the markup can help with that later.) I won't be doing this now I'd rather agree on the new markup feature first. The markup feature looks fine to me. The markup syntax adds some information even for those reading the raw source. Yes and I forgot to mention that it has a extra feature compared to the current module doc parser. It does look for markup on the **whole** file unlike current module doc parser which only parse the header (at the beginning of the file). So with my proposal you can perfectly document a script in the middle of the file or as usual just in front of the concerned macro/function/var. This may be easier for doc maintenance because the function/macro would be closer to its doc. This could be further used for user script that could be documented this way as well. My idea for user script doc support may be to add an extra cdoc command that would be dedicated to documentation of script files: a) cdoc --help-command-list yourscript.cmake b) cdoc --help-variable-list yourscript.cmake c) cdoc --help yourscript.cmake may spit out: a) the doc for macro/function in the concerned script b) the doc for variables c) all doc this command may have more versatile option to include or exclude (cmake/ctest/cpack) doc and/or add some path where to parse all *.cmake files etc An alternative would be to defined something like: CMAKE_USER_DOC_PATHS CPACK_USER_DOC_PATHS CTEST_USER_DOC_PATHS cmake already supports CMAKE_MODULE_PATH for generating help, e.g. like this: $ cmake -DCMAKE_MODULE_PATH=$HOME/src/kdelibs/cmake/modules/ --help-custom- modules This generates docs for all cmake files in CMAKE_MODULE_PATH. --help-module also looks in CMAKE_MODULE_PATH. I'm not sure it needs a new variable. 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-developers] Improving CPack Documentation (and may be others as well)
2012/1/25 Alexander Neundorf neund...@kde.org: On Wednesday 25 January 2012, Eric Noulard wrote: cmake already supports CMAKE_MODULE_PATH for generating help, e.g. like this: $ cmake -DCMAKE_MODULE_PATH=$HOME/src/kdelibs/cmake/modules/ --help-custom- modules This generates docs for all cmake files in CMAKE_MODULE_PATH. --help-module also looks in CMAKE_MODULE_PATH. I'm not sure it needs a new variable. Right, my idea was different than the current --help-module because I intend to get variable or command using --help-variable-* --help-command-* for (may be user) scripts files. This is not the same as generating all doc for a bunch of modules. In my case you could do: cmake -DCMAKE_MODULE_PATH=$HOME/src/kdelibs/cmake/modules/ --help-command-list and get all commands defined (in fact documented) in the module file found in CMAKE_MODULE_PATH. ** this does not work [yet], because currently the list of .cmake files to be loaded for doc parsing is builtin the C++ code ** Nevertheless, Alex is right we can use user provided CMAKE_MODULE_PATH, no need to add more vars. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/3] The CMake Ninja generator.
On Tue, Jan 03, 2012 at 01:15:17AM +, Peter Collingbourne wrote: On Sat, Nov 12, 2011 at 02:36:04AM +, Peter Collingbourne wrote: Hi, These patches add the Ninja generator to CMake, which I am now proposing for inclusion in mainline. [...] This patch series is also available from my git repository: git://github.com/pcc/CMake.git ninja-generator-pr I've now updated the above repository with the changes suggested in this thread. Is there anything else required for this to be merged to next? Ping. Branch has been updated with miscellaneous fixes for Mac OS X bringing the total number of test failures on a Mac down to 4. I don't have time to fix the rest (which mainly relate to the construction of apps/bundles/frameworks) so I will leave this to anyone who cares enough about OS X to fix. Thanks, -- Peter -- 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] fixup_bundle already-fixed-up dependencies
Already tried, doesn't help. example of output: warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' is not absolute... warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' does not exist... /usr/bin/otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) On 24.01.2012, at 23:27, Michael Jackson wrote: I think you need to feed BundleUtilities another argument that lists where to find the ogre frameworks. I think. ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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] fixup_bundle already-fixed-up dependencies
On Wednesday, January 25, 2012, Nikolay Kasyanov corrm...@gmail.com wrote: Already tried, doesn't help. example of output: warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' is not absolute... warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' does not exist... /usr/bin/otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) On 24.01.2012, at 23:27, Michael Jackson wrote: I think you need to feed BundleUtilities another argument that lists where to find the ogre frameworks. I think. ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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 I think in this case, you're going to have to copy the Ogre framework into your bundle before calling fixup_bundle. How did the Ogre framework end up pre-fixed up? That seems unusual... HTH, David -- 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] fixup_bundle already-fixed-up dependencies
Thanks, this way works. Ogre framework is pre-fixed up because it's from Ogre SDK, i.e. should be ready for redistribution, I think. On 25.01.2012, at 16:00, David Cole wrote: On Wednesday, January 25, 2012, Nikolay Kasyanov corrm...@gmail.com wrote: Already tried, doesn't help. example of output: warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' is not absolute... warning: target '@executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre' does not exist... /usr/bin/otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) otool: can't open file: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (No such file or directory) On 24.01.2012, at 23:27, Michael Jackson wrote: I think you need to feed BundleUtilities another argument that lists where to find the ogre frameworks. I think. ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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 I think in this case, you're going to have to copy the Ogre framework into your bundle before calling fixup_bundle. How did the Ogre framework end up pre-fixed up? That seems unusual... HTH, David -- 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 still broken post-2.8.1
Just to be clear: that doesn't mean CMake is right -- it's not passing all the arguments it should. How to move this forward? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Phil Smith Sent: Saturday, January 21, 2012 4:50 PM To: Brad King Cc: cmake@cmake.org; Bill Hoffman Subject: Re: [CMake] CMake still broken post-2.8.1 Argh, premature send syndrome: the hang is definitely because cc.rex is missing arguments and thus invokes the actual, two-stage C compiler without a source file. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Saturday, January 21, 2012 3:45 PM To: Phil Smith Cc: Bill Hoffman; cmake@cmake.org Subject: Re: [CMake] CMake still broken post-2.8.1 On 1/21/2012 12:24 PM, Phil Smith wrote: GOOD C:/Program Files/Regina/regina.exe cc.rex dcc.exe CMakeCCompilerId.c -- arg=[C:/Program Files/Regina/regina.exe] -- arg=[cc.rex dcc.exe] -- arg=[CMakeCCompilerId.c] [snip] BAD c:/Program Files/Regina/regina.exe cc.rex;dcc.exe CMakeCCompilerId.c -- arg=[c:/Program Files/Regina/regina.exe] -- arg=[cc.rex] -- arg=[dcc.exe] -- arg=[CMakeCCompilerId.c] [snip] GOOD: dcc.exe -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c C:/SVN/zFPE/CMakeFiles/CMakeTmp/testCCompiler.c Exiting cc.rex, rc=0 [snip] BAD: dcc.exe CMakeCCompilerId.c Can you reproduce these two results by running the two different command lines on a dummy .c file by hand at a command prompt? -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://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] CMake + NSIS on windows
Since I still don't get CMake + NSIS running on Linux, I was trying to build my software on Windows... I installed CMake and NSIS and all my CMake actually does is to create an installer: cmake_minimum_required(VERSION 2.6) project(try_out) install( # is this automatically the source dir?? DIRECTORY one two DESTINATION test_ddest COMPONENT dirs ) include(CPack) From my understanding I first need to run CMake which actually creates all the files which can be also read from cpack. Now the problem is that it complains the my C compiler is not set correctly. But why does it care in the first place? I mean there are no instructions there which might imply that it needs to compile something, so why should it be set? Thanks, Andrea -- 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 + NSIS on windows
On 01/25/2012 02:28 PM, Andrea Crotti wrote: Since I still don't get CMake + NSIS running on Linux, I was trying to build my software on Windows... I installed CMake and NSIS and all my CMake actually does is to create an installer: cmake_minimum_required(VERSION 2.6) project(try_out) install( # is this automatically the source dir?? DIRECTORY one two DESTINATION test_ddest COMPONENT dirs ) include(CPack) Ok I think I understood by myself, I just need to set project(try_out NONE) to avoid checks of any language and it doesn't complain anymore.. -- 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 + NSIS on windows
Now however CMake complains that it can't fin nmake, which from my search it's something it's this: http://superuser.com/questions/146577/where-do-i-find-nmake-for-windows-7 so cmake . generated by default the nmake files, but why cpack would need nmake for in the first place if I'm just using NSIS? Is this really a dependency which should be also installed? -- 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 + NSIS on windows
On 1/25/2012 9:28 AM, Andrea Crotti wrote: Since I still don't get CMake + NSIS running on Linux, I was trying to build my software on Windows... CMake and NSIS has never been ported to work on Linux, so no surprise there. I installed CMake and NSIS and all my CMake actually does is to create an installer: cmake_minimum_required(VERSION 2.6) project(try_out) install( # is this automatically the source dir?? DIRECTORY one two DESTINATION test_ddest COMPONENT dirs ) include(CPack) From my understanding I first need to run CMake which actually creates all the files which can be also read from cpack. Now the problem is that it complains the my C compiler is not set correctly. But why does it care in the first place? I mean there are no instructions there which might imply that it needs to compile something, so why should it be set? The project command by default asks for c/c++ compiler. You want: project(NONE) cmake --help-command project Set a name for the entire project. project(projectname [languageName1 languageName2 ... ] ) Sets the name of the project. Additionally this sets the variables projectName_BINARY_DIR and projectName_SOURCE_DIR to the respective values. Optionally you can specify which languages your project supports. Example languages are CXX (i.e. C++), C, Fortran, etc. By default C and CXX are enabled. E.g. if you do not have a C++ compiler, you can disable the check for it by explicitly listing the languages you want to support, e.g. C. By using the special language NONE all checks for any language can be disabled. Thanks, Andrea -- 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 -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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 + NSIS on windows
On 01/25/2012 02:49 PM, Bill Hoffman wrote: On 1/25/2012 9:28 AM, Andrea Crotti wrote: Since I still don't get CMake + NSIS running on Linux, I was trying to build my software on Windows... CMake and NSIS has never been ported to work on Linux, so no surprise there. Wait, this contradicts the long thread cpack -G NSIS, where Eric says that my examples work perfectly for him on Linux, while they still don't work for me.. Thanks -- 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 still broken post-2.8.1
On 1/25/2012 9:06 AM, Phil Smith wrote: Just to be clear: that doesn't mean CMake is right -- it's not passing all the arguments it should. How to move this forward? IMO the change to CMake that exposed this was correct. The ARG1 has always been a literal string placed in command shells after the compiler command. This is how it was treated everywhere except in the compiler id detection, which uses execute_process instead of a command shell to run the compiler. That was a bug because it was not running the compiler during identification in the same way that it runs the compiler in the generated build system. The change in question fixed that bug by separating the arguments like they would be in the generated command lines. The only remaining possible fix to that is to do a better job of separating the arguments like a shell would by honoring quoted arguments with spaces, but that would not make a difference in your case because there are no quotes inside the argument value itself (only quotes in the CMake language syntax). In your case, the code SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe) tells CMake to generate command lines in the build system like regina.exe cc.rex dcc.exe ... because the second argument is placed literally on the command line. Prior to the change in question CMake was doing this most of the time but not during compiler identification. Now it is fixed. It's unfortunate that the bug fix to CMake exposed this bug in your project, but that is something you'll have to fix in your project. We've also provided other approaches elsewhere in this thread to avoid the problem altogether by setting up your toolchain file to skip compiler id detection. I consider this matter closed. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake still broken post-2.8.1
We've also provided other approaches elsewhere in this thread to avoid the problem altogether by setting up your toolchain file to skip compiler id detection. OK, I'm willing to do that, but I can't figure out how to do so. It seems like: SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe) SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe) need to change to SET(CMAKE_FORCE_C_COMPILER something) SET(CMAKE_FORCE_CXX_COMPILER something) but I've tried various somethings with no luck. I suspect this is complicated by the fact that my compiler is a multi-token invocation (regina.exe cc.rex dcc.exe). I tried: SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe Dignus) SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe Dignus and SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe Dignus) SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe Dignus) I'm out of ideas, but it sounds like we're on a path to resolution?! -- 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 still broken post-2.8.1
On 1/25/2012 10:53 AM, Phil Smith wrote: We've also provided other approaches elsewhere in this thread to avoid the problem altogether by setting up your toolchain file to skip compiler id detection. OK, I'm willing to do that, but I can't figure out how to do so. Actually the previous discussion was about skipping the test for a working compiler as well as the compiler id. There is a mid ground that can skip just the id part but keep everything else the same. It seems like: SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe) SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe) Keep those lines and add SET(CMAKE_C_COMPILER_ID_RUN 1) SET(CMAKE_C_PLATFORM_ID ) SET(CMAKE_C_COMPILER_ID ) SET(CMAKE_CXX_COMPILER_ID_RUN 1) SET(CMAKE_CXX_PLATFORM_ID ) SET(CMAKE_CXX_COMPILER_ID ) Fill in the ID values if you need to. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] visual studio macros
Hello,
I have tried with the pre-built ones, but those don't detect visual
studio 2005 SP1 correctly on windows 7 64-bit. I had to change the code
to the version below.
I needed to add the Wow6432Node in the registry key path. Also, the
VisualStudioProjectsLocation registry key was not there, but the
VisualStudioLocation key was available on windows XP and on win7. So I
constructed the path using that instead. Now it works for me.
Best regards,
Tom,
// Some VS8 sp0 versions cannot run macros.
// See http://support.microsoft.com/kb/928209
const char* vc8sp1Registry =
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0\\
InstalledProducts\\KB926601;;
const char* vc8exSP1Registry =
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0\\
InstalledProducts\\KB926748;;
std::string vc8sp1;
if (!cmSystemTools::ReadRegistryValue(vc8sp1Registry, vc8sp1)
!cmSystemTools::ReadRegistryValue(vc8exSP1Registry, vc8sp1))
{
return ;
}
std::string base;
std::string path;
// base begins with the VisualStudioProjectsLocation reg value...
if (cmSystemTools::ReadRegistryValue(
HKEY_CURRENT_USER\\Software\\Microsoft\\VisualStudio\\8.0;
VisualStudioLocation,
base))
{
cmSystemTools::ConvertToUnixSlashes(base);
// 8.0 macros folder:
path = base + /Projects/VSMacros80;
}
Op 25/01/2012 17:34, David Cole schreef:
After emailing directly with Tom, I realized I misinterpreted this
code when I replied to the list
He has the problem with a 64-bit build of CMake itself, I think:
You built a 64-bit CMake? That might be the explanation. Try building
a 32-bit one instead. Or simply use Kitware's pre-built 32-bit
binaries. They work just fine on 64-bit Windows systems...
Tom, please let us know if a 32-bit CMake fixes this issue for you or not.
Thanks,
David C.
On Tue, Jan 24, 2012 at 10:28 AM, David Coledavid.c...@kitware.com wrote:
From the CMake source code file Source/cmGlobalVisualStudio8Generator.cxx:
//
std::string cmGlobalVisualStudio8Generator::GetUserMacrosDirectory()
{
// Some VS8 sp0 versions cannot run macros.
// See http://support.microsoft.com/kb/928209
const char* vc8sp1Registry =
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0\\
InstalledProducts\\KB926601;;
const char* vc8exSP1Registry =
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0\\
InstalledProducts\\KB926748;;
std::string vc8sp1;
if (!cmSystemTools::ReadRegistryValue(vc8sp1Registry, vc8sp1)
!cmSystemTools::ReadRegistryValue(vc8exSP1Registry, vc8sp1))
{
return ;
}
Since you mention you have SP1 installed, (KB926601), we skip copying
the macros files for your installation since we know they will not
work. We also will not even try to call the macro, even if you copy it
into place by hand. See the Microsoft URL in the source code comment
for more details...
If you want to try to use this functionality anyway, you'll have to
modify CMake's code to avoid the return statement in the above code.
HTH,
David
On Tue, Jan 24, 2012 at 5:10 AM, Tom Deblauwetom.debla...@traficon.com wrote:
Hello,
I'm running a Windows 7 64 bit OS, and I'm using visual studio 2005 with
service pack 1. Below is the list of versions. Now my question is: how can I
manually check that all macro stuff works and is configured correctly? In
other words: how can I install the macro's manually? They are definitely not
showing up automaticaly in the macro explorer. Also, when is the time that
CMake installs those macros in visual studio? Is it when the project files
are generated or at install time of cmake itself? How are the macros then
eventually run, what triggers them?
Best regards,
Tom,
Microsoft Visual Studio 2005
Version 8.0.50727.867 (vsvista.050727-8600)
Microsoft .NET Framework
Version 2.0.50727 SP2
Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1
(KB926601)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB2251481)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB2465367)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB2538218)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB2548826)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB937061)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB971023)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB971090)
Security Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB973673)
Update for Microsoft Visual Studio 2005 Professional Edition - ENU
(KB932232)
--
Tom Deblauwe
RD Engineer
Traficon International N.V.
Vlamingstraat 19
B-8560 Wevelgem
Belgium
Tel.: +32 (0)56 37.22.00
Fax: +32 (0)56 37.21.96
Re: [CMake] CMake + NSIS on windows
On 01/25/2012 02:48 PM, Andrea Crotti wrote: Now however CMake complains that it can't fin nmake, which from my search it's something it's this: http://superuser.com/questions/146577/where-do-i-find-nmake-for-windows-7 so cmake . generated by default the nmake files, but why cpack would need nmake for in the first place if I'm just using NSIS? Is this really a dependency which should be also installed? From reading here http://www.cmake.org/Wiki/CMake:Packaging_With_CPack I think is exactly what I would like to do, using cpack directly without cmake and nmake. But it also doesn't work, in the sense that it still needs NMake. After I downloaded everything (SDK and visual studio express) it finally worked, but I really don't see why cpack should need to make anything.. Is that really necessary / unavoidable? Because that would mean that it's probably not a good idea, since NSIS would do the same as NSIS + CMake + SDK + visual studio expres.. -- 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] [New Module] Arduino CMake
On Wednesday 25 January 2012, Alfa Omega wrote: A little addendum to what I wrote earlier. On Wed, Jan 25, 2012 at 8:54 AM, Alfa Omega queezythegr...@gmail.comwrote: 2012/1/24 Alexander Neundorf a.neundorf-w...@gmx.net Hi, On Tuesday 24 January 2012, Alfa Omega wrote: Hi, What part does not follow the convention? I'm using a toolchain file, plus when I was writing this I based it on a existing module bundled with CMake (but cant remember which). I'm open to modifying my project to match the convention. If you could point out which parts don't quite meet the convention, I would greatly appreciate that. The functions in ArduinoProcessing.cmake should have a common prefix to show where they come from, e.g. ARDUINO_ ArduinoProcessing.cmake is a prototype, and isn't used with Arduino CMake, so you can ignore that. Same for the functions in FindArduino.cmake The documentation for the functions should be at the top of the file, so when cmake generates documentation, it will be included. The documentation for the module is located at the top (only those two function should be used), all other function are for internal use (but are documented). When I originally wrote this, I wanted to hide as much of the boilerplate code as I could (hence I wanted people to use those two functions documentated at the top). Now I'm starting to think that apart from setup_arduino_compiler and setup_arduino_core (which could be merged into one) everything else could be used if someone who wanted control the build process manually. So that's why the documentation for the rest of the function where omitted from the top. Ok. Still they should all use the arduino_ prefix. setup_arduino_compiler() looks wrong. What do you mean by it looks wrong (the name might not be the best :))? Do you mean setup_arduino_compiler and setup_arduino_core should be merged? Well, this should be done in the host/compiler setup steps, i.e. in Arduino.cmake and Arduino-GNU-C.cmake and Arduino-GNU-CXX.cmake (this is using gcc, right ?). Did you consider adding Arduino as operating system ? Then you could add a Platforms/Arduino.cmake which is loaded automatically when CMAKE_SYSTEM_NAME is set to Arduino. Ah, I just see, you did. Is there are reason why you didn't put all the functions, settings, etc. there ? Then it wouldn't be necessary to use FindArduino.cmake when you already know you are building for Arduino. (e.g. there is no FindWindows.cmake, you simply are on Windows, or the cmake run fails). That is a good point, but then how could I specify that I want a specific minimal version? The toolchain file should be mostly done after the first three set() calls you have. More or less all of the rest should be in Arduino.cmake or Arduino-GNU- C/CXX.cmake. What is the best way to initialize the compiler flags? And where should I move the rest of the stuff that in the toolchain file? See above, in the platform specific files. The functions for setting up additional targets look ok. What should find_sources() be used for ? It's used for getting all the sources located at specified path, because there is some processing of the sources (for Arduino library detection based on the header includes). Can you please explain more ? Are these source files from the user, or are they part of arduino ? 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] CTest: Glob files to include in coverage report with 0% line coverage
I am not sure where I found info on this variable, but the ITK/VTK projects are always a good resource on the latest trends/development in CMake/CTest/CPack. Further, for anyone interested, please note the difference in CTEST_EXTRA_COVERAGE_GLOB, which lists glob expressions as used by file (GLOB), and CTEST_CUSTOM_COVERAGE_EXCLUDE, which uses regular expressions. In the beginning, I wasn't very clear about this, but in either case you would need to use /test/* or /test/.*, respectively, to include/exclude all files in some test/ directory. Regarding this variable, I was eventually looking at the source code and figured that indeed only source files in the source tree are considered. Related bug report: http://public.kitware.com/Bug/view.php?id=12910 Andreas On Tue, Jan 24, 2012 at 7:12 AM, David Cole david.c...@kitware.com wrote: On Tue, Jan 24, 2012 at 2:51 AM, Eric Noulard eric.noul...@gmail.com wrote: 2012/1/24 Rolf Eike Beer e...@sf-mail.de: Andreas Schuh wrote: Hi, Setting CTEST_EXTRA_COVERAGE_GLOB in the CTestCustom.cmake file can be used to add additional files which shall be included in the coverage report. This is useful to ensure that files which are not covered by any test are still reported with 0% line coverage. Oh, interesting variable. How can it be that there is absolutely zero documentation for in CMake? Because ctest and cpack documentation are very far from being documented as cmake is ? E.g. current ctest and cpack do not have --help-variable-* support? If you want to help please try my stage/ImproveCPackDoc-reloaded branch and may be read this: http://public.kitware.com/Bug/view.php?id=10067 The technique I propose may be used for cpack, ctest, etc... -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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 There is zero documentation for all of the ctest related variables. We need somebody who can write a bunch of documentation someday to fill in that blank. -- 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] CTest: Glob files to include in coverage report with 0% line coverage
BTW In my own project, I am using a bit more old-school approach to document also CMake code. I wrote a Doxygen filter which transforms the CMake code into C code which Doxygen can generate an HTML documentation for. The source of this filter implemented in Python can be found at http://sourceforge.net/p/sbia-basis/code/ci/77b8ae5d7ec2b201366c09f295d09076b9927527/tree/src/tools/doxyfilter-cmake.py. See, for example, http://www.rad.upenn.edu/sbia/software/doxygen/basis/trunk/html/group__CMakeAPI.html http://www.rad.upenn.edu/sbia/software/doxygen/basis/trunk/html/group__BasisSettings.html http://www.rad.upenn.edu/sbia/software/doxygen/basis/trunk/html/group__BasisSettings.html#gab06414cfca0fcb6d2202e2e8a23cf009 On Wed, Jan 25, 2012 at 12:34 PM, Andreas Schuh andreas.schuh...@googlemail.com wrote: I am not sure where I found info on this variable, but the ITK/VTK projects are always a good resource on the latest trends/development in CMake/CTest/CPack. Further, for anyone interested, please note the difference in CTEST_EXTRA_COVERAGE_GLOB, which lists glob expressions as used by file (GLOB), and CTEST_CUSTOM_COVERAGE_EXCLUDE, which uses regular expressions. In the beginning, I wasn't very clear about this, but in either case you would need to use /test/* or /test/.*, respectively, to include/exclude all files in some test/ directory. Regarding this variable, I was eventually looking at the source code and figured that indeed only source files in the source tree are considered. Related bug report: http://public.kitware.com/Bug/view.php?id=12910 Andreas On Tue, Jan 24, 2012 at 7:12 AM, David Cole david.c...@kitware.com wrote: On Tue, Jan 24, 2012 at 2:51 AM, Eric Noulard eric.noul...@gmail.com wrote: 2012/1/24 Rolf Eike Beer e...@sf-mail.de: Andreas Schuh wrote: Hi, Setting CTEST_EXTRA_COVERAGE_GLOB in the CTestCustom.cmake file can be used to add additional files which shall be included in the coverage report. This is useful to ensure that files which are not covered by any test are still reported with 0% line coverage. Oh, interesting variable. How can it be that there is absolutely zero documentation for in CMake? Because ctest and cpack documentation are very far from being documented as cmake is ? E.g. current ctest and cpack do not have --help-variable-* support? If you want to help please try my stage/ImproveCPackDoc-reloaded branch and may be read this: http://public.kitware.com/Bug/view.php?id=10067 The technique I propose may be used for cpack, ctest, etc... -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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 There is zero documentation for all of the ctest related variables. We need somebody who can write a bunch of documentation someday to fill in that blank. -- 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] CMake still broken post-2.8.1
On 1/25/2012 1:50 PM, Phil Smith wrote:
Ok, that *maybe* gets me further. CMakeDetermineASM_DIGNUSCompiler.cmake (in
Modules\) is:
SET(ASM_DIALECT _DIGNUS)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT asmit.bat)
INCLUDE(CMakeDetermineASMCompiler)
SET(ASM_DIALECT)
and that gets invoked several times, with:
dasm.exe --version
dasm.exe -h
dasm.exe -qversion
dasm.exe -V
...none of which work. Maybe I need to force something for the assembler?
Or should asmit.bat just return 0 for any of those?
Assembly support was very immature as of 2.8.0 and has been modified
since then. I've heard complaints that some incompatibilities were
introduced but never worked with it myself.
Alex?
Oh, I did also try the recommended lines, both as listed and as:
SET(CMAKE_C_COMPILER_ID_RUN 1)
SET(CMAKE_C_PLATFORM_ID DIGNUS)
SET(CMAKE_C_COMPILER_ID DIGNUS)
SET(CMAKE_CXX_COMPILER_ID_RUN 1)
SET(CMAKE_CXX_PLATFORM_ID DIGNUS)
SET(CMAKE_CXX_COMPILER_ID DIGNUS
I'm not sure DIGNUS was the right ID to try, but it didn't seem to make any
difference.
It won't make a difference unless CMake has a matching Platform/*
and/or Compiler/* information module available in CMAKE_MODULE_PATH.
If it works without that then don't worry about it.
The problem here, of course, is that I don't understand what it's *trying* to do
The relevant process is documented here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalGenerator.cxx;hb=v2.8.6#l152
During CMakeDetermine(LANG)Compiler CMake figures out what compiler
the user is asking it to choose for a LANGuage (via either the
environment or a toolchain file). Then it runs that compiler in
the CMakeDetermineCompilerId module to detect the compiler vendor.
From that name the CMake(LANG)Information.cmake step loads matching
Platform/* and Compiler/* modules that contain information about how
to generate build rules for that compiler.
-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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake still broken post-2.8.1
On Wednesday 25 January 2012, Brad King wrote:
On 1/25/2012 1:50 PM, Phil Smith wrote:
Ok, that *maybe* gets me further. CMakeDetermineASM_DIGNUSCompiler.cmake
(in Modules\) is:
SET(ASM_DIALECT _DIGNUS)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT asmit.bat)
INCLUDE(CMakeDetermineASMCompiler)
SET(ASM_DIALECT)
and that gets invoked several times, with:
dasm.exe --version
dasm.exe -h
dasm.exe -qversion
dasm.exe -V
...none of which work. Maybe I need to force something for the assembler?
Or should asmit.bat just return 0 for any of those?
This is cmak trying to recognize which assembler this is by looking at the
output of the assembler,
This is e.g. what GNU as says:
hammer:~$ as --version
GNU assembler (Linux/GNU Binutils) 2.21.51.0.6.20110118
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-slackware-linux'.
There is then a regexp in CMakeDetermineASMCompiler.cmake, which recognizes
this as the GNU assembler.
Does dasm.exe have a command line switch which just makes it print its name
and version number and exit ?
This should be added to CMakeDetermineASMCompiler.cmake then.
...or you preset CMAKE_ASM_DIGNUS_COMPILER_ID to DIGNUS.
Assembly support was very immature as of 2.8.0 and has been modified
since then. I've heard complaints that some incompatibilities were
introduced but never worked with it myself.
Yes. It should be much better now.
But I didn't follow that whole thread...
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] CMake still broken post-2.8.1
No, there's no What version are you? flag for dasm.
I added
set(CMAKE_ASM_DIGNUS_COMPILER_ID DIGNUS)
and now it seems to be invoking regina.exe with just the -o flag. Is that the
right SET ?
-Original Message-
From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net]
Sent: Wednesday, January 25, 2012 2:46 PM
To: cmake@cmake.org; Phil Smith
Subject: Re: [CMake] CMake still broken post-2.8.1
On Wednesday 25 January 2012, Brad King wrote:
On 1/25/2012 1:50 PM, Phil Smith wrote:
Ok, that *maybe* gets me further. CMakeDetermineASM_DIGNUSCompiler.cmake
(in Modules\) is:
SET(ASM_DIALECT _DIGNUS)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT asmit.bat)
INCLUDE(CMakeDetermineASMCompiler)
SET(ASM_DIALECT)
and that gets invoked several times, with:
dasm.exe --version
dasm.exe -h
dasm.exe -qversion
dasm.exe -V
...none of which work. Maybe I need to force something for the assembler?
Or should asmit.bat just return 0 for any of those?
This is cmak trying to recognize which assembler this is by looking at the
output of the assembler,
This is e.g. what GNU as says:
hammer:~$ as --version
GNU assembler (Linux/GNU Binutils) 2.21.51.0.6.20110118
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-slackware-linux'.
There is then a regexp in CMakeDetermineASMCompiler.cmake, which recognizes
this as the GNU assembler.
Does dasm.exe have a command line switch which just makes it print its name
and version number and exit ?
This should be added to CMakeDetermineASMCompiler.cmake then.
...or you preset CMAKE_ASM_DIGNUS_COMPILER_ID to DIGNUS.
Assembly support was very immature as of 2.8.0 and has been modified
since then. I've heard complaints that some incompatibilities were
introduced but never worked with it myself.
Yes. It should be much better now.
But I didn't follow that whole thread...
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] CMake still broken post-2.8.1
On Wednesday 25 January 2012, Phil Smith wrote: No, there's no What version are you? flag for dasm. I added set(CMAKE_ASM_DIGNUS_COMPILER_ID DIGNUS) and now it seems to be invoking regina.exe with just the -o flag. Is that the right SET ? Looks good, are you sure this is still from the compiler ID detection ? Add some debugging output to CMakeDetermineASMCompiler.cmake, this should show you what it going on. Or run cmake --trace, that prints line by line what cmake valuates. 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] CPACK and NSIS: Download a msi-installer and install it didn't work
2012/1/25 Ralf Lange ralf.la...@longsoft.de: Hello, I will prepare a windows installer for my application. The application need GStreamer for Windows. The installer has to download the installer and start the installer. I have add the following command to the CMakeLists.txt file: SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS NSISdl::download http://ossbuild.googlecode.com/files/GStreamer-WinBuilds-GPL-x86.msi $INSTDIRGStreamer-WinBuilds-GPL-x86.msi ExecWait 'msiexec /i \\\$INSTDIRGStreamer-WinBuilds-GPL-x86.msi\\\ /passive ' Delete \\\$INSTDIRGStreamer-WinBuilds-GPL-x86.msi\\\ ) But when I start the installer, there is no download, no installation and no error message. Did you set the variable **before** include(CPack) ? What's the reason? Did you check that the project.nsi file generated by CPack contains your specific extra install commands? The file may be found in buildtree/_CPack_Packages/systemname/NSIS/project.nsi -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] CMake + NSIS on windows
2012/1/25 Bill Hoffman bill.hoff...@kitware.com: On 1/25/2012 9:28 AM, Andrea Crotti wrote: Since I still don't get CMake + NSIS running on Linux, I was trying to build my software on Windows... CMake and NSIS has never been ported to work on Linux, so no surprise there. In fact there is. It works for me when NSIS package cross-compiled win32 binaries or even in the stupid not usable case of packaging Linux binaries in a Windows NSIS installer. The only interesting case (I think) is the cross-compiled one. I use NSIS from Debian repo. You can try for yourself with the CERTI project specified here: http://www.cmake.org/pipermail/cmake/2011-December/048157.html The fact is I did not manage to understand WHY it doesn't work for Andrea, because I'm simply not able to reproduce the problem, see: http://www.cmake.org/pipermail/cmake/2012-January/048548.html Andrea is not alone trying this: http://www.cmake.org/pipermail/cmake/2011-December/048123.html but Hendrik in the end manage to do it... but even if I know HOW it make it work: His last (private) message was: I solved my NSIS CPack problems. Now I use mingw and nsis from Suse Build Service and all is working fine. I don't know the origin of the error in the first place. The apparent error at that time was again not set CPACK_TOPLEVEL_DIRECTORY: http://www.cmake.org/pipermail/cmake/2011-December/048165.html but I am not able to reproduce such error and reading the code get me no-where either. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] ExternalProject unexpected behavior
Hi, I'm trying to build a very big project with some third party dependencies, so I want to use ExternalProject capabilities. I'm deploying on OSX with Xcode. If I do: (on the build dir) $ cmake src_dir -Dargs $ xcodebuild (or open the project with Xcode) Then build, everything works great. But, if I refer to him as an external project like so (in a CMakeLists.txt) include(ExternalProject) ExternalProject_Add(PROJ1 SOURCE_DIR src_dir CMAKE_ARGS -Dargs) Then it fails building that specific target. Reading the resulting cache, some logs, etc, I've observed that, only when including via ExternalProject: 1. This fails to find the size: include(CheckTypeSize) CHECK_TYPE_SIZE(void* PROJ1_PTR_SIZE BUILTIN_TYPES_ONLY) if (PROJ1_PTR_SIZE EQUAL 8) ... else () ... endif () 2. Cache matches different values than when building standalone. 3. Some find_package() calls doesn't work the same way (no same results). If I understood properly, ExternalProject should generate projects that behave the same way than standalone ones. Is this correct? Why this happens? What I'm doing wrong? Is it because there's no support for ExternalProject and Xcode? Thanks. -- 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] execute a script before and after configuration
On 01/21/2012 11:28 AM, Dominik Szczerba wrote:
On Sat, Jan 21, 2012 at 10:50 AM, Dominik Szczerba domi...@itis.ethz.ch
wrote:
You might use an EXECUTE_PROCESS() command at the beginning of your
CMakeLists.txt to unload the modules, and another EXECUTE_PROCESS()
at the end to reload them.
Will try, thanks for the hint!
Unfortunately, it does not work. Unloading the module via a call to a
bash script only unloads it for this script's process - the test run
is not affected. Instead of calling the script I tried sourcing it
(like 'source script', so the whole current session is affected) but
this in turn seems to somehow silently do nothing, it does not even
seem to be called.
Still dead end, any more ideas? It would be nice to have a general
elegant solution for cases where user is not allowed to directly run
their programs on the current node. Similar scenario will arise for
executing tests - currently make test fails because the tests are
built for the scheduler so will not run locally.
Regards,
Dominik
If I understand correctly - ATM, I've no access to a Cray machine, so
I can't investigate immediately - the modules are unloaded/reloaded
for the current process and its children only, but not for the CMake
process where it is actually needed, right? If so, and provided you
can figure out how to unload/reload the modules by C program code,
you might use the hardly deployed LOAD_COMMAND(), look here:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MODULES C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR})
ADD_LIBRARY(UnloadModules MODULE EXCLUDE_FROM_ALL UnloadModules.c)
SET_TARGET_PROPERTIES(UnloadModules PROPERTIES
OUTPUT_NAME cmUnloadModules)
FIND_LIBRARY(UNLOAD_MODULES_LIBRARY cmUnloadModules ${CMAKE_BINARY_DIR})
ADD_LIBRARY(ReloadModules MODULE EXCLUDE_FROM_ALL ReloadModules.c)
SET_TARGET_PROPERTIES(ReloadModules PROPERTIES
OUTPUT_NAME cmReloadModules)
FIND_LIBRARY(RELOAD_MODULES_LIBRARY cmReloadModules ${CMAKE_BINARY_DIR})
ADD_CUSTOM_TARGET(ModulesLoading)
ADD_DEPENDENCIES(ModulesLoading UnloadModules ReloadModules)
IF(UNLOAD_MODULES_LIBRARY AND RELOAD_MODULES_LIBRARY)
LOAD_COMMAND(UnloadModules ${CMAKE_BINARY_DIR})
MESSAGE(UnloadModules: ${CMAKE_LOADED_COMMAND_UnloadModules})
UNLOAD_MODULES()
EXECUTE_PROCESS(
COMMAND sh -c echo \CMake process: \$(pidof cmake)\)
ENDIF()
# Do usual stuff here.
IF(UNLOAD_MODULES_LIBRARY AND RELOAD_MODULES_LIBRARY)
LOAD_COMMAND(ReloadModules ${CMAKE_BINARY_DIR})
MESSAGE(ReloadModules: ${CMAKE_LOADED_COMMAND_ReloadModules})
RELOAD_MODULES()
EXECUTE_PROCESS(
COMMAND sh -c echo \CMake process: \$(pidof cmake)\)
ENDIF()
/* UnloadModules.c: */
#include cmCPluginAPI.h
#include unistd.h
#include stdio.h
void UnloadModulesInit(cmLoadedCommandInfo *);
static int initialpass(void *, void *, int, char *[]);
void UnloadModulesInit(cmLoadedCommandInfo *info)
{
info-Name = UNLOAD_MODULES;
info-InitialPass = initialpass;
}
static int initialpass(void *i, void *f, int argc, char *argv[])
{
printf(Unloading modules for process: %d\n,getpid());
return !0;
}
/* ReloadModules.c: */
#include cmCPluginAPI.h
#include unistd.h
#include stdio.h
void ReloadModulesInit(cmLoadedCommandInfo *);
static int initialpass(void *, void *, int, char *[]);
void ReloadModulesInit(cmLoadedCommandInfo *info)
{
info-Name = RELOAD_MODULES;
info-InitialPass = initialpass;
}
static int initialpass(void *i, void *f, int argc, char *argv[])
{
printf(Reloading modules for process: %d\n,getpid());
return !0;
}
The cmCPluginAPI.h header is the one from the CMake code base.
The basic idea is that the new commands are executed in the context of
the CMake process and, thus, can influence the latter, and this is not
true for commands spawned by EXECUTE_PROCESS(). As long as the {Un,Re}
loadModules targets aren't built, everything works as usual, but after
make ModulesLoading, a reconfiguration invokes the UNLOAD_MODULES()
and RELOAD_MODULES() commands which exemplarily shows the PID of the
CMake process. Therefore, if you manage to unload/reload the modules
via the two initialpass() functions, this might be a practicable way.
Refer to [1] for more information about such LOAD_COMMAND() plugins.
Alternatively, if it's possible to unload/reload the modules for an
arbitrary process, e.g. by module -p PID un/load , you might
use the above-noted example's means to find out the PID of the CMake
process and use it with EXECUTE_PROCESS().
A final remark: If I use the following executable CMake script
#!/bin/sh
if [ $1 != -E ]; then
echo Unloading modules
cmake -DCMAKE_COMMAND=$0 $@
echo Reloading modules
else
cmake $@
fi
for the initial configuration, I can see the {Un,Re}loading modules
messages appearing around each further automatic reconfiguration, e.g.
after touching CMakeLists.txt and rebuilding. Thus, Eike's
Re: [CMake] CPACK and NSIS: Download a msi-installer and install it didn't work
The variable is set bevor include(CPack) and the generated nsi file locks OK. I test the installer on a 32bit Windows7 system and it works, but on a 64bit Windows7 system it works not. So I think it is a NSIS problem, not a CPACK problem. Thanks for the tips. Ralf Am Mittwoch, den 25.01.2012, 22:33 +0100 schrieb Eric Noulard: 2012/1/25 Ralf Lange ralf.la...@longsoft.de: Hello, I will prepare a windows installer for my application. The application need GStreamer for Windows. The installer has to download the installer and start the installer. I have add the following command to the CMakeLists.txt file: SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS NSISdl::download http://ossbuild.googlecode.com/files/GStreamer-WinBuilds-GPL-x86.msi $INSTDIRGStreamer-WinBuilds-GPL-x86.msi ExecWait 'msiexec /i \\\$INSTDIRGStreamer-WinBuilds-GPL-x86.msi\\\ /passive ' Delete \\\$INSTDIRGStreamer-WinBuilds-GPL-x86.msi\\\ ) But when I start the installer, there is no download, no installation and no error message. Did you set the variable **before** include(CPack) ? What's the reason? Did you check that the project.nsi file generated by CPack contains your specific extra install commands? The file may be found in buildtree/_CPack_Packages/systemname/NSIS/project.nsi -- 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, master, updated. v2.8.7-150-gc6a33dc
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 c6a33dce36598b224a6e44485275022356c9ccfd (commit) via 27bc9e2631a2f7b6d78064f5adf0b528982a2de7 (commit) via 84079c92ca5c401e35aefacbcca25e0ac3e644d6 (commit) from 31c53c288c3644cc357684124e566baf9a07a1a1 (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=c6a33dce36598b224a6e44485275022356c9ccfd commit c6a33dce36598b224a6e44485275022356c9ccfd Merge: 31c53c2 27bc9e2 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:14:38 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:14:38 2012 -0500 Merge topic 'FindProtobuf_import_dirs' 27bc9e2 FindProtobuf: Update documentation comment for 2.8.8 84079c9 FindProtobuf: Merge patch that allows extra import dirs --- Summary of changes: Modules/FindProtobuf.cmake | 13 + 1 files changed, 13 insertions(+), 0 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, master, updated. v2.8.7-155-g9d57dfe
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 9d57dfee6ad7b8d6eb0b7ce45256a456ddadf0d8 (commit) via bb2b264b5ed76428319a428949a54ba76f71004d (commit) via 7053a00f237c5d510a9a64566139b76ce82dffdc (commit) via 44ba7a3da8682316c8a53a266e06edceb038ef4d (commit) via 8e8672ccdbd6ddc9e0847cbab5b6d1dc6e95c5f7 (commit) from c6a33dce36598b224a6e44485275022356c9ccfd (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=9d57dfee6ad7b8d6eb0b7ce45256a456ddadf0d8 commit 9d57dfee6ad7b8d6eb0b7ce45256a456ddadf0d8 Merge: c6a33dc bb2b264 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:14:49 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:14:49 2012 -0500 Merge topic 'openssl-version' bb2b264 FindOpenSSL: also parse version number define with uppercase letters 7053a00 FindOpenSSL: only try to parse opensslv.h if it exists 44ba7a3 Merge branch 'master' of git://cmake.org/cmake into openssl-version 8e8672c FindOpenSSL: improve version number handling --- Summary of changes: Modules/FindOpenSSL.cmake | 40 1 files changed, 32 insertions(+), 8 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, master, updated. v2.8.7-172-g2e69c05
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 2e69c0534fb78ac728a4dab75d75df0eec8a6589 (commit) via 55c3435d88618d7ed935736604e7ab989cef4b28 (commit) from a1c1350a1f4c95fa9d2746da5e8528b6e6ed90b0 (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=2e69c0534fb78ac728a4dab75d75df0eec8a6589 commit 2e69c0534fb78ac728a4dab75d75df0eec8a6589 Merge: a1c1350 55c3435 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:16:22 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:16:22 2012 -0500 Merge topic 'FindPkgConfig-REQUIRED-issue-12620' 55c3435 FindPkgConfig: respect REQUIRED (#12620) --- Summary of changes: Modules/FindPkgConfig.cmake |6 ++ 1 files changed, 2 insertions(+), 4 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, master, updated. v2.8.7-174-gac1c2a0
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 ac1c2a00b1660d7581eb95f5fccb0261d91b0d83 (commit) via 26015baba36c8c48b2b72ca2b0ddb7ba0b37d6ad (commit) from 2e69c0534fb78ac728a4dab75d75df0eec8a6589 (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=ac1c2a00b1660d7581eb95f5fccb0261d91b0d83 commit ac1c2a00b1660d7581eb95f5fccb0261d91b0d83 Merge: 2e69c05 26015ba Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:16:39 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:16:39 2012 -0500 Merge topic 'FPHSA-CONFIG_MODE-doc' 26015ba FindPackageHandleStandardArgs: fix documentation --- Summary of changes: Modules/FindPackageHandleStandardArgs.cmake |6 +++--- 1 files changed, 3 insertions(+), 3 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, master, updated. v2.8.7-176-g352279c
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 352279cdc28940ff116d7c63005b029fc0a9b3d4 (commit) via 1531c11168ad3e629e504af32d7ddc4435fbc3c7 (commit) from ac1c2a00b1660d7581eb95f5fccb0261d91b0d83 (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=352279cdc28940ff116d7c63005b029fc0a9b3d4 commit 352279cdc28940ff116d7c63005b029fc0a9b3d4 Merge: ac1c2a0 1531c11 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:16:52 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:16:52 2012 -0500 Merge topic 'loadcommand-test-cleanup' 1531c11 LoadCommand test: cleanup --- Summary of changes: Tests/LoadCommand/CMakeCommands/CMakeLists.txt |3 --- Tests/LoadCommand/CMakeLists.txt |6 -- Tests/LoadCommand/LoadedCommand.h.in |6 -- 3 files changed, 0 insertions(+), 15 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, master, updated. v2.8.7-182-g476679a
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 476679afaf99cb4d3f436499f0fef89f5590ca0d (commit)
via 98d20316bdf701865a3e3c4df7d378917224b8b0 (commit)
via 36d66416f4f47ecf0cf84b1618b60bb7d853f2e5 (commit)
via 0d96decdd069451c9b805e411abe0fc6225c8ee9 (commit)
via 880139a6421649b9b3ff8048418cd556e7ddf2c1 (commit)
via 9a6b102205045e457db24bd00777ef000c30e242 (commit)
from 352279cdc28940ff116d7c63005b029fc0a9b3d4 (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=476679afaf99cb4d3f436499f0fef89f5590ca0d
commit 476679afaf99cb4d3f436499f0fef89f5590ca0d
Merge: 352279c 98d2031
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Jan 25 11:17:12 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 25 11:17:12 2012 -0500
Merge topic 'GetPrerequisites-rpath-OSX'
98d2031 Fix BundleUtilities test failure with space in build path.
36d6641 Fix new BundleUtilities test failure on Mac 10.4.x
0d96dec GetPrerequisites: Add test for @rpath support.
880139a GetPrerequisites: Add support for @rpath on Mac OS X.
9a6b102 GetPrerequisites: Add support for @rpath on Mac OS X.
---
Summary of changes:
Modules/GetPrerequisites.cmake | 29
Tests/BundleUtilities/CMakeLists.txt | 49
.../{testbundleutils2.cpp = testbundleutils3.cpp} |8 ++--
3 files changed, 82 insertions(+), 4 deletions(-)
copy Tests/BundleUtilities/{testbundleutils2.cpp = testbundleutils3.cpp} (60%)
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, master, updated. v2.8.7-184-gf47fea9
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 f47fea95d7e07cfa634210337036a03dae3539c9 (commit) via 3dc6f2bfb34ff90a905b10872e98c163940f456a (commit) from 476679afaf99cb4d3f436499f0fef89f5590ca0d (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=f47fea95d7e07cfa634210337036a03dae3539c9 commit f47fea95d7e07cfa634210337036a03dae3539c9 Merge: 476679a 3dc6f2b Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:17:29 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:17:29 2012 -0500 Merge topic 'find-threads-11333' 3dc6f2b FindThreads: Try pthreads with no special option first (#11333) --- Summary of changes: Modules/FindThreads.cmake | 47 ++-- 1 files changed, 28 insertions(+), 19 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, master, updated. v2.8.7-188-g055999a
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 055999a1ef5c87908f8e02f3688d0bdf5399ac51 (commit) via 7da35e655047e595b46628c9d5c569b8d71b51c0 (commit) from 30620e74770e52ff4b2b03850d3ed3f0e21921a3 (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=055999a1ef5c87908f8e02f3688d0bdf5399ac51 commit 055999a1ef5c87908f8e02f3688d0bdf5399ac51 Merge: 30620e7 7da35e6 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:17:55 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:17:55 2012 -0500 Merge topic 'emacs-mode-indent-issue-12908' 7da35e6 cmake-mode.el: Indent after multiline argument (#12908) --- Summary of changes: Docs/cmake-mode.el |1 + 1 files changed, 1 insertions(+), 0 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, master, updated. v2.8.7-190-g5ee225d
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 5ee225dbbd500ac316ce9750d7b5a9f4a8692c43 (commit) via ede3ec5a799768482a7bc37ac44da99817b62316 (commit) from 055999a1ef5c87908f8e02f3688d0bdf5399ac51 (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=5ee225dbbd500ac316ce9750d7b5a9f4a8692c43 commit 5ee225dbbd500ac316ce9750d7b5a9f4a8692c43 Merge: 055999a ede3ec5 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:18:03 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:18:03 2012 -0500 Merge topic 'use-pkgconfig-quiet' ede3ec5 use pkg_check_modules() quiet in other modules --- Summary of changes: Modules/FindGnuTLS.cmake |4 ++-- Modules/FindLibXml2.cmake |4 ++-- Modules/FindLibXslt.cmake |2 +- Modules/FindOpenSSL.cmake |6 ++ 4 files changed, 7 insertions(+), 9 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, master, updated. v2.8.7-192-g825b9dd
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 825b9dde3d391169ad0546b4458f1d3e1bc88756 (commit) via a5fd3915c9a0562f1e97aa38692ade0200c8ba28 (commit) from 5ee225dbbd500ac316ce9750d7b5a9f4a8692c43 (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=825b9dde3d391169ad0546b4458f1d3e1bc88756 commit 825b9dde3d391169ad0546b4458f1d3e1bc88756 Merge: 5ee225d a5fd391 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:18:18 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:18:18 2012 -0500 Merge topic 'improve-libxml2' a5fd391 FindLibXml2: support version selection --- Summary of changes: Modules/FindLibXml2.cmake | 10 -- 1 files changed, 8 insertions(+), 2 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, master, updated. v2.8.7-196-gc8b7f8e
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 c8b7f8e36503a370fce8bf873300110d65d56550 (commit) via a803a622d052e6b50873f6bf6a3ab224f656333f (commit) from 8372bd98a9d5df29a483e8b43266ed928cba9ebe (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=c8b7f8e36503a370fce8bf873300110d65d56550 commit c8b7f8e36503a370fce8bf873300110d65d56550 Merge: 8372bd9 a803a62 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:18:41 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:18:41 2012 -0500 Merge topic 'improve-findgit' a803a62 FindGit: support version number --- Summary of changes: Modules/FindGit.cmake | 17 - 1 files changed, 16 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, master, updated. v2.8.7-200-g55e7d40
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 55e7d4071f15f4a39df49ca930ca5686c8ff1494 (commit) via 7f81c48bdd7901a310744c3b65a8a975cd9cf1a6 (commit) from 1226207a6e93c1ef480c1ce7859cae1977be7eab (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=55e7d4071f15f4a39df49ca930ca5686c8ff1494 commit 55e7d4071f15f4a39df49ca930ca5686c8ff1494 Merge: 1226207 7f81c48 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:19:09 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:19:09 2012 -0500 Merge topic 'improve-findexpat' 7f81c48 FindEXPAT: support version number --- Summary of changes: Modules/FindEXPAT.cmake | 24 +++- 1 files changed, 23 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, master, updated. v2.8.7-202-gddc1eb5
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 ddc1eb5ecdc72b0ba2c4bad1a36a7a6875646248 (commit) via c1b884965f86e2622f55d261259fc2a148035f5b (commit) from 55e7d4071f15f4a39df49ca930ca5686c8ff1494 (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=ddc1eb5ecdc72b0ba2c4bad1a36a7a6875646248 commit ddc1eb5ecdc72b0ba2c4bad1a36a7a6875646248 Merge: 55e7d40 c1b8849 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:19:25 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:19:25 2012 -0500 Merge topic 'improve-findcurl' c1b8849 FindCURL: support version selection --- Summary of changes: Modules/FindCURL.cmake | 19 +++ 1 files changed, 15 insertions(+), 4 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, master, updated. v2.8.7-211-g731f996
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 731f996ce070bbba1b4913050497afa95436f2d2 (commit) via 5b6ca9fa3feb4a3c611d496b63cb72149db25cfc (commit) via 40fb00512a95dd5b07f8e767a5e2b713c7299d5f (commit) from dc3fb5ac4eeb60c489d4435e28982920fc586a8a (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=731f996ce070bbba1b4913050497afa95436f2d2 commit 731f996ce070bbba1b4913050497afa95436f2d2 Merge: dc3fb5a 5b6ca9f Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:20:00 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 11:20:00 2012 -0500 Merge topic 'improve-findbzip2' 5b6ca9f FindBZip2: add support for debug libraries (#12867) 40fb005 FindBZip2: add support for version checking --- Summary of changes: Modules/FindBZip2.cmake | 26 -- 1 files changed, 20 insertions(+), 6 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.7-2251-g86edc3c
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 86edc3ce1d5cb2e3cd1bd40c81cb0d4254ebc6b3 (commit) via 731f996ce070bbba1b4913050497afa95436f2d2 (commit) via dc3fb5ac4eeb60c489d4435e28982920fc586a8a (commit) via c444cf73dd3ffb7e1bea552cdea015af5f56981b (commit) via ddc1eb5ecdc72b0ba2c4bad1a36a7a6875646248 (commit) via 55e7d4071f15f4a39df49ca930ca5686c8ff1494 (commit) via 1226207a6e93c1ef480c1ce7859cae1977be7eab (commit) via c8b7f8e36503a370fce8bf873300110d65d56550 (commit) via 8372bd98a9d5df29a483e8b43266ed928cba9ebe (commit) via 825b9dde3d391169ad0546b4458f1d3e1bc88756 (commit) via 5ee225dbbd500ac316ce9750d7b5a9f4a8692c43 (commit) via 055999a1ef5c87908f8e02f3688d0bdf5399ac51 (commit) via 30620e74770e52ff4b2b03850d3ed3f0e21921a3 (commit) via f47fea95d7e07cfa634210337036a03dae3539c9 (commit) via 476679afaf99cb4d3f436499f0fef89f5590ca0d (commit) via 352279cdc28940ff116d7c63005b029fc0a9b3d4 (commit) via ac1c2a00b1660d7581eb95f5fccb0261d91b0d83 (commit) via 2e69c0534fb78ac728a4dab75d75df0eec8a6589 (commit) via a1c1350a1f4c95fa9d2746da5e8528b6e6ed90b0 (commit) via 3c5489bd0f124945022a0ff36e0915f63ea59915 (commit) via d05d71389aba168aa7cb4d95f5b22de0ce02596c (commit) via 5737cdbcbd459f4d7c270f5ed95ac698894979fd (commit) via cef75ca90944a45ced82d9a53a592b3526a408af (commit) via 9d57dfee6ad7b8d6eb0b7ce45256a456ddadf0d8 (commit) via c6a33dce36598b224a6e44485275022356c9ccfd (commit) via 31c53c288c3644cc357684124e566baf9a07a1a1 (commit) from c4abb5c845185a7a8c302a891c81d07449cefc37 (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=86edc3ce1d5cb2e3cd1bd40c81cb0d4254ebc6b3 commit 86edc3ce1d5cb2e3cd1bd40c81cb0d4254ebc6b3 Merge: c4abb5c 731f996 Author: David Cole david.c...@kitware.com AuthorDate: Wed Jan 25 11:21:10 2012 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Wed Jan 25 11:21:10 2012 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.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
[Cmake-commits] CMake branch, next, updated. v2.8.7-2253-gda1c1c3
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 da1c1c3067df653dbc51fb6d12ae00aebe40ec72 (commit)
via 393c2e14fbb60c18d90d82383d89a6cba59b57fe (commit)
from 86edc3ce1d5cb2e3cd1bd40c81cb0d4254ebc6b3 (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=da1c1c3067df653dbc51fb6d12ae00aebe40ec72
commit da1c1c3067df653dbc51fb6d12ae00aebe40ec72
Merge: 86edc3c 393c2e1
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 11:41:28 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 25 11:41:28 2012 -0500
Merge topic 'findruby-no-dummy-version' into next
393c2e1 FindRuby: do not blindly set version to 1.8.0
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=393c2e14fbb60c18d90d82383d89a6cba59b57fe
commit 393c2e14fbb60c18d90d82383d89a6cba59b57fe
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 17:26:43 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Jan 25 17:34:09 2012 +0100
FindRuby: do not blindly set version to 1.8.0
RUBY_VERSION was always set, even if no RUBY_EXECUTABLE was found. While it
may make sense to assume a default version if we can't execute the binary,
it
certainly doesn't make sense to report a version if there is no executable
at
all.
diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake
index 5d6c98a..3fd2ded 100644
--- a/Modules/FindRuby.cmake
+++ b/Modules/FindRuby.cmake
@@ -139,7 +139,7 @@ ENDIF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
# In case RUBY_EXECUTABLE could not be executed (e.g. cross compiling)
# try to detect which version we found. This is not too good.
-IF(NOT RUBY_VERSION_MAJOR)
+IF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
# by default assume 1.8.0
SET(RUBY_VERSION_MAJOR 1)
SET(RUBY_VERSION_MINOR 8)
@@ -149,8 +149,7 @@ IF(NOT RUBY_VERSION_MAJOR)
SET(RUBY_VERSION_MAJOR 1)
SET(RUBY_VERSION_MINOR 9)
ENDIF(${RUBY_EXECUTABLE} MATCHES ruby1.?9 OR RUBY_HDR_DIR)
-ENDIF(NOT RUBY_VERSION_MAJOR)
-
+ENDIF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
SET(RUBY_VERSION
${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR}.${RUBY_VERSION_PATCH})
SET(_RUBY_VERSION_SHORT ${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR})
---
Summary of changes:
Modules/FindRuby.cmake |5 ++---
1 files changed, 2 insertions(+), 3 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.7-2259-g8f6a445
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 8f6a445ce9be7175797a5a809e97342af0f442a6 (commit)
via 680fecf1cf0886c523d5bd48e7445c3724d7fd93 (commit)
from 36c3e77609a978b115fb1c8a0d6006ace23385f1 (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=8f6a445ce9be7175797a5a809e97342af0f442a6
commit 8f6a445ce9be7175797a5a809e97342af0f442a6
Merge: 36c3e77 680fecf
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 12:16:21 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 25 12:16:21 2012 -0500
Merge topic 'findruby-no-dummy-version' into next
680fecf FindRuby: fix syntax errors if ruby is not installed
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=680fecf1cf0886c523d5bd48e7445c3724d7fd93
commit 680fecf1cf0886c523d5bd48e7445c3724d7fd93
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 18:16:05 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Jan 25 18:16:05 2012 +0100
FindRuby: fix syntax errors if ruby is not installed
diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake
index 3fd2ded..c4adfd1 100644
--- a/Modules/FindRuby.cmake
+++ b/Modules/FindRuby.cmake
@@ -151,10 +151,12 @@ IF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
ENDIF(${RUBY_EXECUTABLE} MATCHES ruby1.?9 OR RUBY_HDR_DIR)
ENDIF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
-SET(RUBY_VERSION
${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR}.${RUBY_VERSION_PATCH})
-SET(_RUBY_VERSION_SHORT ${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR})
-SET(_RUBY_VERSION_SHORT_NODOT ${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR})
-SET(_RUBY_NODOT_VERSION
${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR}${RUBY_VERSION_PATCH})
+IF(RUBY_VERSION_MAJOR)
+ SET(RUBY_VERSION
${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR}.${RUBY_VERSION_PATCH})
+ SET(_RUBY_VERSION_SHORT ${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR})
+ SET(_RUBY_VERSION_SHORT_NODOT ${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR})
+ SET(_RUBY_NODOT_VERSION
${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR}${RUBY_VERSION_PATCH})
+ENDIF(RUBY_VERSION_MAJOR)
FIND_PATH(RUBY_INCLUDE_DIR
NAMES ruby.h
@@ -166,7 +168,7 @@ FIND_PATH(RUBY_INCLUDE_DIR
SET(RUBY_INCLUDE_DIRS ${RUBY_INCLUDE_DIR} )
# if ruby 1.8 is required or if ruby 1.8 was found, search for the
config.h dir
-IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
+IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
FIND_PATH(RUBY_CONFIG_INCLUDE_DIR
NAMES ruby/config.h config.h
HINTS
@@ -175,7 +177,7 @@ IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT
)
SET(RUBY_INCLUDE_DIRS ${RUBY_INCLUDE_DIRS} ${RUBY_CONFIG_INCLUDE_DIR} )
-ENDIF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
+ENDIF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
# Determine the list of possible names for the ruby library
---
Summary of changes:
Modules/FindRuby.cmake | 14 --
1 files changed, 8 insertions(+), 6 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.7-2263-ga50d29c
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 a50d29c3e955b9409c4a1c260d869036f37b9e4d (commit)
via 0051506aa4ea3e1fdbe5333b529a0a5af9476be5 (commit)
from 5338178fafd77e2d027f5f70dbb23f941a4e23ca (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=a50d29c3e955b9409c4a1c260d869036f37b9e4d
commit a50d29c3e955b9409c4a1c260d869036f37b9e4d
Merge: 5338178 0051506
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 12:29:13 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 25 12:29:13 2012 -0500
Merge topic 'improve-findpng' into next
0051506 FindPNG: support version selection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0051506aa4ea3e1fdbe5333b529a0a5af9476be5
commit 0051506aa4ea3e1fdbe5333b529a0a5af9476be5
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 18:24:44 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Jan 25 18:24:57 2012 +0100
FindPNG: support version selection
diff --git a/Modules/FindPNG.cmake b/Modules/FindPNG.cmake
index f616973..a6c181c 100644
--- a/Modules/FindPNG.cmake
+++ b/Modules/FindPNG.cmake
@@ -7,6 +7,7 @@
# PNG_LIBRARIES, the libraries to link against to use PNG.
# PNG_DEFINITIONS - You should add_definitons(${PNG_DEFINITIONS}) before
compiling code that includes png library files.
# PNG_FOUND, If false, do not try to use PNG.
+# PNG_VERSION_STRING - the version of the PNG library found (since CMake
2.8.8)
# Also defined, but not for general use are
# PNG_LIBRARY, where to find the PNG library.
# For backward compatiblity the variable PNG_INCLUDE_DIR is also set. It has
the same value as PNG_INCLUDE_DIRS.
@@ -56,11 +57,19 @@ if(ZLIB_FOUND)
endif (PNG_LIBRARY AND PNG_PNG_INCLUDE_DIR)
+ if (PNG_PNG_INCLUDE_DIR AND EXISTS ${PNG_PNG_INCLUDE_DIR}/png.h)
+ file(STRINGS ${PNG_PNG_INCLUDE_DIR}/png.h png_version_str REGEX
^#define[ \t]+PNG_LIBPNG_VER_STRING[ \t]+\.+\)
+
+ string(REGEX REPLACE ^#define[ \t]+PNG_LIBPNG_VER_STRING[
\t]+\([^\]+)\.* \\1 PNG_VERSION_STRING ${png_version_str})
+ unset(png_version_str)
+ endif (PNG_PNG_INCLUDE_DIR AND EXISTS ${PNG_PNG_INCLUDE_DIR}/png.h)
endif(ZLIB_FOUND)
# handle the QUIETLY and REQUIRED arguments and set PNG_FOUND to TRUE if
# all listed variables are TRUE
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-find_package_handle_standard_args(PNG DEFAULT_MSG PNG_LIBRARY
PNG_PNG_INCLUDE_DIR)
+find_package_handle_standard_args(PNG
+ REQUIRED_VARS PNG_LIBRARY PNG_PNG_INCLUDE_DIR
+ VERSION_VAR PNG_VERSION_STRING)
mark_as_advanced(PNG_PNG_INCLUDE_DIR PNG_LIBRARY )
---
Summary of changes:
Modules/FindPNG.cmake | 11 ++-
1 files changed, 10 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.7-2265-g62d2fd6
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 62d2fd6dcd199f67a0c3ef5c279384d17fdbcfaa (commit)
via e01fe583b80208b1cd28f429cfac9c866453a994 (commit)
from a50d29c3e955b9409c4a1c260d869036f37b9e4d (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=62d2fd6dcd199f67a0c3ef5c279384d17fdbcfaa
commit 62d2fd6dcd199f67a0c3ef5c279384d17fdbcfaa
Merge: a50d29c e01fe58
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 12:37:38 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 25 12:37:38 2012 -0500
Merge topic 'improve-findtclsh' into next
e01fe58 FindTclsh: support version selection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e01fe583b80208b1cd28f429cfac9c866453a994
commit e01fe583b80208b1cd28f429cfac9c866453a994
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 18:37:00 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Jan 25 18:37:25 2012 +0100
FindTclsh: support version selection
diff --git a/Modules/FindTCL.cmake b/Modules/FindTCL.cmake
index 13f32f8..f2c776f 100644
--- a/Modules/FindTCL.cmake
+++ b/Modules/FindTCL.cmake
@@ -48,10 +48,14 @@ INCLUDE(CMakeFindFrameworks)
INCLUDE(FindTclsh)
INCLUDE(FindWish)
-GET_FILENAME_COMPONENT(TCL_TCLSH_PATH ${TCL_TCLSH} PATH)
-GET_FILENAME_COMPONENT(TCL_TCLSH_PATH_PARENT ${TCL_TCLSH_PATH} PATH)
-STRING(REGEX REPLACE
- ^.*tclsh([0-9]\\.*[0-9]).*$ \\1 TCL_TCLSH_VERSION ${TCL_TCLSH})
+IF(TCLSH_VERSION_STRING)
+ SET(TCL_TCLSH_VERSION ${TCLSH_VERSION_STRING})
+ELSE(TCLSH_VERSION_STRING)
+ GET_FILENAME_COMPONENT(TCL_TCLSH_PATH ${TCL_TCLSH} PATH)
+ GET_FILENAME_COMPONENT(TCL_TCLSH_PATH_PARENT ${TCL_TCLSH_PATH} PATH)
+ STRING(REGEX REPLACE
+^.*tclsh([0-9]\\.*[0-9]).*$ \\1 TCL_TCLSH_VERSION ${TCL_TCLSH})
+ENDIF(TCLSH_VERSION_STRING)
GET_FILENAME_COMPONENT(TK_WISH_PATH ${TK_WISH} PATH)
GET_FILENAME_COMPONENT(TK_WISH_PATH_PARENT ${TK_WISH_PATH} PATH)
diff --git a/Modules/FindTclsh.cmake b/Modules/FindTclsh.cmake
index 8fde59e..a45f285 100644
--- a/Modules/FindTclsh.cmake
+++ b/Modules/FindTclsh.cmake
@@ -82,9 +82,19 @@ FIND_PROGRAM(TCL_TCLSH
HINTS ${TCLTK_POSSIBLE_BIN_PATHS}
)
+IF(TCL_TCLSH)
+ EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E echo puts \$tcl_version
+ COMMAND ${TCL_TCLSH}
+ OUTPUT_VARIABLE TCLSH_VERSION_STRING
+ ERROR_QUIET
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+ENDIF(TCL_TCLSH)
+
# handle the QUIETLY and REQUIRED arguments and set TIFF_FOUND to TRUE if
# all listed variables are TRUE
INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(Tclsh DEFAULT_MSG TCL_TCLSH)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Tclsh
+ REQUIRED_VARS TCL_TCLSH
+ VERSION_VAR TCLSH_VERSION_STRING)
MARK_AS_ADVANCED(TCL_TCLSH)
---
Summary of changes:
Modules/FindTCL.cmake | 12
Modules/FindTclsh.cmake | 12 +++-
2 files changed, 19 insertions(+), 5 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.7-2268-g477edad
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 477edad8eb9f1d13e5e405766c2a363df6a7ecc8 (commit) via f9c1c6225c4366918465b86e4c6976ecc266245f (commit) via ca39c5cdd1ca28516791e00f213d6dee2179c6df (commit) from 62d2fd6dcd199f67a0c3ef5c279384d17fdbcfaa (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=477edad8eb9f1d13e5e405766c2a363df6a7ecc8 commit 477edad8eb9f1d13e5e405766c2a363df6a7ecc8 Merge: 62d2fd6 f9c1c62 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 25 14:44:16 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 14:44:16 2012 -0500 Merge topic 'imported-target-visibility' into next f9c1c62 Add test covering imported target scope rules ca39c5c Optionally allow IMPORTED targets to be globally visible http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9c1c6225c4366918465b86e4c6976ecc266245f commit f9c1c6225c4366918465b86e4c6976ecc266245f Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 25 14:04:26 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jan 25 14:43:07 2012 -0500 Add test covering imported target scope rules diff --git a/Tests/CMakeOnly/CMakeLists.txt b/Tests/CMakeOnly/CMakeLists.txt index 20e6a3a..96b9972 100644 --- a/Tests/CMakeOnly/CMakeLists.txt +++ b/Tests/CMakeOnly/CMakeLists.txt @@ -16,3 +16,5 @@ add_CMakeOnly_test(CheckSymbolExists) add_CMakeOnly_test(CheckCXXSymbolExists) add_CMakeOnly_test(AllFindModules) + +add_CMakeOnly_test(TargetScope) diff --git a/Tests/CMakeOnly/TargetScope/CMakeLists.txt b/Tests/CMakeOnly/TargetScope/CMakeLists.txt new file mode 100644 index 000..fa5d8e2 --- /dev/null +++ b/Tests/CMakeOnly/TargetScope/CMakeLists.txt @@ -0,0 +1,13 @@ +cmake_minimum_required (VERSION 2.8) +project(TargetScope NONE) + +add_subdirectory(Sub) + +if(TARGET SubLibLocal) + message(FATAL_ERROR SubLibLocal visible in top directory) +endif() +if(NOT TARGET SubLibGlobal) + message(FATAL_ERROR SubLibGlobal not visible in top directory) +endif() + +add_subdirectory(Sib) diff --git a/Tests/CMakeOnly/TargetScope/Sib/CMakeLists.txt b/Tests/CMakeOnly/TargetScope/Sib/CMakeLists.txt new file mode 100644 index 000..7f6f4e8 --- /dev/null +++ b/Tests/CMakeOnly/TargetScope/Sib/CMakeLists.txt @@ -0,0 +1,6 @@ +if(TARGET SubLibLocal) + message(FATAL_ERROR SubLibLocal visible in sibling directory) +endif() +if(NOT TARGET SubLibGlobal) + message(FATAL_ERROR SubLibGlobal not visible in sibling directory) +endif() diff --git a/Tests/CMakeOnly/TargetScope/Sub/CMakeLists.txt b/Tests/CMakeOnly/TargetScope/Sub/CMakeLists.txt new file mode 100644 index 000..27318f5 --- /dev/null +++ b/Tests/CMakeOnly/TargetScope/Sub/CMakeLists.txt @@ -0,0 +1,9 @@ +add_library(SubLibLocal UNKNOWN IMPORTED) +add_library(SubLibGlobal UNKNOWN IMPORTED GLOBAL) +add_subdirectory(Sub) +if(NOT TARGET SubLibLocal) + message(FATAL_ERROR SubLibLocal not visible in own directory) +endif() +if(NOT TARGET SubLibGlobal) + message(FATAL_ERROR SubLibGlobal not visible in own directory) +endif() diff --git a/Tests/CMakeOnly/TargetScope/Sub/Sub/CMakeLists.txt b/Tests/CMakeOnly/TargetScope/Sub/Sub/CMakeLists.txt new file mode 100644 index 000..a351daa --- /dev/null +++ b/Tests/CMakeOnly/TargetScope/Sub/Sub/CMakeLists.txt @@ -0,0 +1,6 @@ +if(NOT TARGET SubLibLocal) + message(FATAL_ERROR SubLibLocal not visible in subdirectory) +endif() +if(NOT TARGET SubLibGlobal) + message(FATAL_ERROR SubLibGlobal not visible in subdirectory) +endif() http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca39c5cdd1ca28516791e00f213d6dee2179c6df commit ca39c5cdd1ca28516791e00f213d6dee2179c6df Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 25 13:39:26 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jan 25 14:42:31 2012 -0500 Optionally allow IMPORTED targets to be globally visible Consider the case motivating commit e01cce28 (Allow add_dependencies() on imported targets, 2010-11-19). An imported target references a file generated at build time by a custom target on which it depends. Had the file been built directly using add_library or add_executable its target name would have been visible globally. Therefore the imported target representing the file should be globally visible also. Teach the IMPORTED signature of add_(executable|library) to accept a new GLOBAL option to make the imported target visible globally. diff --git a/Source/cmAddExecutableCommand.cxx b/Source/cmAddExecutableCommand.cxx index bac2430..6dd8e5c
[Cmake-commits] CMake branch, next, updated. v2.8.7-2270-g3a3bf6b
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 3a3bf6b45c55b8634821508d5e889d649767b6f3 (commit) via 7d20619fbea357103f44ee219923d44922cf9641 (commit) from 477edad8eb9f1d13e5e405766c2a363df6a7ecc8 (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=3a3bf6b45c55b8634821508d5e889d649767b6f3 commit 3a3bf6b45c55b8634821508d5e889d649767b6f3 Merge: 477edad 7d20619 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 25 16:27:22 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 25 16:27:22 2012 -0500 Merge topic 'doc-IMPORTED-properties' into next 7d20619 Clarify IMPORTED_ target property documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d20619fbea357103f44ee219923d44922cf9641 commit 7d20619fbea357103f44ee219923d44922cf9641 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 25 16:17:43 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jan 25 16:26:40 2012 -0500 Clarify IMPORTED_ target property documentation These properties are meant to be set to tell CMake something, not read to get information from CMake. diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 6a937b8..1a68cee 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -323,7 +323,8 @@ void cmTarget::DefineProperties(cmake *cm) cm-DefineProperty (IMPORTED_CONFIGURATIONS, cmProperty::TARGET, Configurations provided for an IMPORTED target., - Lists configuration names available for an IMPORTED target. + Set this to the list of configuration names available for an + IMPORTED target. The names correspond to configurations defined in the project from which the target is imported. If the importing project uses a different set of configurations @@ -334,14 +335,12 @@ void cmTarget::DefineProperties(cmake *cm) cm-DefineProperty (IMPORTED_IMPLIB, cmProperty::TARGET, Full path to the import library for an IMPORTED target., - Specifies the location of the \.lib\ part of a windows DLL. + Set this to the location of the \.lib\ part of a windows DLL. Ignored for non-imported targets.); cm-DefineProperty (IMPORTED_IMPLIB_CONFIG, cmProperty::TARGET, - Per-configuration version of IMPORTED_IMPLIB property., - This property is used when loading settings for the CONFIG - configuration of an imported target. + CONFIG-specific version of IMPORTED_IMPLIB property., Configuration names correspond to those provided by the project from which the target is imported.); @@ -351,8 +350,10 @@ void cmTarget::DefineProperties(cmake *cm) Shared libraries may be linked to other shared libraries as part of their implementation. On some platforms the linker searches for the dependent libraries of shared libraries they are including - in the link. This property lists - the dependent shared libraries of an imported library. The list + in the link. + Set this property to the list of dependent shared libraries of an + imported library. + The list should be disjoint from the list of interface libraries in the IMPORTED_LINK_INTERFACE_LIBRARIES property. On platforms requiring dependent shared libraries to be found at link time CMake uses this @@ -361,9 +362,7 @@ void cmTarget::DefineProperties(cmake *cm) cm-DefineProperty (IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG, cmProperty::TARGET, - Per-configuration version of IMPORTED_LINK_DEPENDENT_LIBRARIES., - This property is used when loading settings for the CONFIG - configuration of an imported target. + CONFIG-specific version of IMPORTED_LINK_DEPENDENT_LIBRARIES., Configuration names correspond to those provided by the project from which the target is imported. If set, this property completely overrides the generic property @@ -372,8 +371,8 @@ void cmTarget::DefineProperties(cmake *cm) cm-DefineProperty (IMPORTED_LINK_INTERFACE_LIBRARIES, cmProperty::TARGET, Transitive link interface of an IMPORTED target., - Lists libraries whose interface is included when an IMPORTED library - target is linked to another target. + Set this to the list of libraries whose interface is included when + an IMPORTED library target is linked to another target. The libraries will be included on the link line for the target. Unlike the LINK_INTERFACE_LIBRARIES property, this property applies to all imported
[Cmake-commits] CMake branch, master, updated. v2.8.7-212-g208569f
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 208569f1da0cf2c481f4b377ad4fe542a3a74e2a (commit) from 731f996ce070bbba1b4913050497afa95436f2d2 (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=208569f1da0cf2c481f4b377ad4fe542a3a74e2a commit 208569f1da0cf2c481f4b377ad4fe542a3a74e2a Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Jan 26 00:05:05 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Jan 26 00:05:05 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 764dc38..edce102 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 01) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 25) +SET(KWSYS_DATE_STAMP_DAY 26) --- Summary of changes: Source/kwsys/kwsysDateStamp.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
[Cmake-commits] CMake branch, next, updated. v2.8.7-2272-g2595ea7
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 2595ea7bdabf97d1a0978ad06ae122fcdb3d823e (commit)
via 409aeafa2518a1cd38709810ba765860ef21aeb8 (commit)
from 3a3bf6b45c55b8634821508d5e889d649767b6f3 (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=2595ea7bdabf97d1a0978ad06ae122fcdb3d823e
commit 2595ea7bdabf97d1a0978ad06ae122fcdb3d823e
Merge: 3a3bf6b 409aeaf
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Thu Jan 26 02:56:48 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 26 02:56:48 2012 -0500
Merge topic 'findruby-no-dummy-version' into next
409aeaf FindRuby: do not blindly set version to 1.8.0
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=409aeafa2518a1cd38709810ba765860ef21aeb8
commit 409aeafa2518a1cd38709810ba765860ef21aeb8
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Jan 25 17:26:43 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Jan 25 18:33:08 2012 +0100
FindRuby: do not blindly set version to 1.8.0
RUBY_VERSION was always set, even if no RUBY_EXECUTABLE was found. While it
may make sense to assume a default version if we can't execute the binary,
it
certainly doesn't make sense to report a version if there is no executable
at
all.
diff --git a/Modules/FindRuby.cmake b/Modules/FindRuby.cmake
index 5d6c98a..c4adfd1 100644
--- a/Modules/FindRuby.cmake
+++ b/Modules/FindRuby.cmake
@@ -139,7 +139,7 @@ ENDIF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
# In case RUBY_EXECUTABLE could not be executed (e.g. cross compiling)
# try to detect which version we found. This is not too good.
-IF(NOT RUBY_VERSION_MAJOR)
+IF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
# by default assume 1.8.0
SET(RUBY_VERSION_MAJOR 1)
SET(RUBY_VERSION_MINOR 8)
@@ -149,13 +149,14 @@ IF(NOT RUBY_VERSION_MAJOR)
SET(RUBY_VERSION_MAJOR 1)
SET(RUBY_VERSION_MINOR 9)
ENDIF(${RUBY_EXECUTABLE} MATCHES ruby1.?9 OR RUBY_HDR_DIR)
-ENDIF(NOT RUBY_VERSION_MAJOR)
+ENDIF(RUBY_EXECUTABLE AND NOT RUBY_VERSION_MAJOR)
-
-SET(RUBY_VERSION
${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR}.${RUBY_VERSION_PATCH})
-SET(_RUBY_VERSION_SHORT ${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR})
-SET(_RUBY_VERSION_SHORT_NODOT ${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR})
-SET(_RUBY_NODOT_VERSION
${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR}${RUBY_VERSION_PATCH})
+IF(RUBY_VERSION_MAJOR)
+ SET(RUBY_VERSION
${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR}.${RUBY_VERSION_PATCH})
+ SET(_RUBY_VERSION_SHORT ${RUBY_VERSION_MAJOR}.${RUBY_VERSION_MINOR})
+ SET(_RUBY_VERSION_SHORT_NODOT ${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR})
+ SET(_RUBY_NODOT_VERSION
${RUBY_VERSION_MAJOR}${RUBY_VERSION_MINOR}${RUBY_VERSION_PATCH})
+ENDIF(RUBY_VERSION_MAJOR)
FIND_PATH(RUBY_INCLUDE_DIR
NAMES ruby.h
@@ -167,7 +168,7 @@ FIND_PATH(RUBY_INCLUDE_DIR
SET(RUBY_INCLUDE_DIRS ${RUBY_INCLUDE_DIR} )
# if ruby 1.8 is required or if ruby 1.8 was found, search for the
config.h dir
-IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
+IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
FIND_PATH(RUBY_CONFIG_INCLUDE_DIR
NAMES ruby/config.h config.h
HINTS
@@ -176,7 +177,7 @@ IF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT
)
SET(RUBY_INCLUDE_DIRS ${RUBY_INCLUDE_DIRS} ${RUBY_CONFIG_INCLUDE_DIR} )
-ENDIF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
+ENDIF( ${Ruby_FIND_VERSION_SHORT_NODOT} GREATER 18 OR
${_RUBY_VERSION_SHORT_NODOT} GREATER 18 OR RUBY_HDR_DIR)
# Determine the list of possible names for the ruby library
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
