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
