[cmake-developers] [CMake 0011494]: FindITK.cmake path list is incomplete
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11494 == Reported By:mrceresa Assigned To: == Project:CMake Issue ID: 11494 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-11-22 12:16 EST Last Modified: 2010-11-22 12:16 EST == Summary:FindITK.cmake path list is incomplete Description: Hello, I'm packaging the InsightToolkit for Fedora. I noticed that the only paths defined in FindITK.cmake are: /usr/local/lib/InsightToolkit /usr/lib/InsightToolkit However the correct path for a Fedora distribution probably is: /usr/share/InsightToolkit As with the current configuration, find_package(ITK) fails, would it be possible to add this path to the FindITK.cmake that is shipped with CMake? I have to admit that I don't understand completely how cmake finds software when there is no Findpackage.cmake so, maybe, this can be fixed without modifying this file! Thanks for any help you can provide on this issue and best regards, Mario == Issue History Date ModifiedUsername FieldChange == 2010-11-22 12:16 mrceresa New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Using cmake pkg-config-like in non-cmake builds
Hi, there can be the case that a package which has been built with cmake, should be used in a project which doesn't use cmake. There is a feature request that cmake should help with generating pkg-config pc-files: http://public.kitware.com/Bug/view.php?id=11446 I don't like that idea, because a) this means duplicating information, and b) doing that in a less powerful format. I have a slightly different idea: instead of having cmake generate pc-files, modify/extend cmake so that it can be used similar to pkg-config by projects which don't use cmake as their buildsystem. I attached a first very quick try to that bug report. It's a small cmake script which can be executed by cmake with -P, and which basically contains one find_package() call and prints the results, so they can be fed into a compiler invocation in a makefile. It already somewhat works: $ cmake -DMODE=COMPILE -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake -I/usr/include -I/usr/include $ cmake -DMODE=LINK -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake /usr/lib/libpng.so /usr/lib/libz.so Do you think this makes sense ? Current issues: * the output goes to stderr instead stdout * the output has line breaks * actual problem: currently it's not possible to use commands which deal with targets in script-mode (I disabled that in 2007 since at least back then it didn't make sense). This means that find-modules which use try_compile() internally fail, and also those which create imported targets. Do you think it is worth to put some effort into this ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using cmake pkg-config-like in non-cmake builds
On 11/22/2010 03:55 PM, Alexander Neundorf wrote: I have a slightly different idea: instead of having cmake generate pc-files, modify/extend cmake so that it can be used similar to pkg-config by projects which don't use cmake as their buildsystem. Interesting. It already somewhat works: $ cmake -DMODE=COMPILE -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake -I/usr/include -I/usr/include $ cmake -DMODE=LINK -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake /usr/lib/libpng.so /usr/lib/libz.so Do you think this makes sense ? Yes. It might be hard to do in non-toy cases though. Current issues: * the output goes to stderr instead stdout * the output has line breaks * actual problem: currently it's not possible to use commands which deal with targets in script-mode (I disabled that in 2007 since at least back then it didn't make sense). This means that find-modules which use try_compile() internally fail, and also those which create imported targets. Consider implementing the outer-most script in bash (or plain bourne shell). Internally it can run cmake on a test project that prints information during its configuration but never builds. Then you can use sed to parse out the results. Do you think it is worth to put some effort into this ? I'm not going to spend time on it but I can review what others produce. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On 11/22/2010 04:06 PM, Alexander Neundorf wrote: On Monday 22 November 2010, Brad King wrote: The warning should be more specific about what cause errors later on means. It could mean both with future versions of CMake and with this version of CMake later on during *this* configuration. The latter is more important. I think this is hard to know. I just meant that the warning text should elaborate in general. The most important information is to make the reader aware that if there are errors involving the module later in the configuration then this may be the cause. The only problem is how to get users building KDE that see an obscure FPHSA argument error over to instructions to add this cmd line option. Perhaps your proposed shadow warning for CMP0017 that appears just before the breakage will help. Yes, I can add something more there. As above. I think the path forward here is: (1) Improve documentation of CMAKE_USER_MAKE_RULES_OVERRIDE[_C] variables (2) Add the Custom-* file inclusion, document it Do you think both (1) and (2) are necessary ? I suppose just (1) is enough. It can be used to implement (2) in a given project. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using cmake pkg-config-like in non-cmake builds
On Monday 22 November 2010, Brad King wrote: On 11/22/2010 03:55 PM, Alexander Neundorf wrote: I have a slightly different idea: instead of having cmake generate pc-files, modify/extend cmake so that it can be used similar to pkg-config by projects which don't use cmake as their buildsystem. Interesting. It already somewhat works: $ cmake -DMODE=COMPILE -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake -I/usr/include -I/usr/include $ cmake -DMODE=LINK -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake /usr/lib/libpng.so /usr/lib/libz.so Do you think this makes sense ? Yes. It might be hard to do in non-toy cases though. Current issues: * the output goes to stderr instead stdout * the output has line breaks * actual problem: currently it's not possible to use commands which deal with targets in script-mode (I disabled that in 2007 since at least back then it didn't make sense). This means that find-modules which use try_compile() internally fail, and also those which create imported targets. Consider implementing the outer-most script in bash (or plain bourne shell). Internally it can run cmake on a test project that prints information during its configuration but never builds. Then you can use sed to parse out the results. Good idea. Do you think it is worth to put some effort into this ? I'm not going to spend time on it but I can review what others produce. Ok :-) Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using cmake pkg-config-like in non-cmake builds
On 2010-11-22 21:55+0100 Alexander Neundorf wrote: Hi, there can be the case that a package which has been built with cmake, should be used in a project which doesn't use cmake. There is a feature request that cmake should help with generating pkg-config pc-files: http://public.kitware.com/Bug/view.php?id=11446 I don't like that idea, because a) this means duplicating information, and b) doing that in a less powerful format. I have a slightly different idea: instead of having cmake generate pc-files, modify/extend cmake so that it can be used similar to pkg-config by projects which don't use cmake as their buildsystem. I attached a first very quick try to that bug report. It's a small cmake script which can be executed by cmake with -P, and which basically contains one find_package() call and prints the results, so they can be fed into a compiler invocation in a makefile. It already somewhat works: $ cmake -DMODE=COMPILE -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake -I/usr/include -I/usr/include $ cmake -DMODE=LINK -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake /usr/lib/libpng.so /usr/lib/libz.so Do you think this makes sense ? Hi Alex: How did you collect that compiler flag information? As far as I know the command install(EXPORT ) only writes out information about the link flags but not the compile flags associated with a given library target. If your method of obtaining compile flag information is general enough, then it should be straightforward to modifiy that install signature to write out the compile flags as well, and that would be a huge win. For example, PLplot currently uses install(EXPORT ) to collect link flag information for all its libraries for the use of external projects. And we use that information for an external CMake-based build system we have implemented to build and exhaustively test our installed examples. That build system would be a lot less cumbersome if we had access to compile flags for each of our libraries through the EXPORTed cmake file. Thus, in answer to your primary question, I think the cmake file written out by install(EXPORT ...) is the right format to use for compile flag and linker flag information if the above suggested enhancement to install(EXPORT...) was made. Once compile and link flag data were collected in a format like that, it should be a simple matter to parse those data into any other form that developers might like including dumping those data directly to the command line as in your proof of concept above. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
