[cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
Hi, when I use a Find-module to search for a package, I get a nice error message if the package could not be found. If I use find_package(Foo) and rely on Config-mode, cmake produces an error message which doesn't help the user: ~/src/extra-cmake-modules/example/b$ make rebuild_cache Running CMake to regenerate build system... CMake Error at CMakeLists.txt:4 (find_package): Could not find module Findextra-cmake-modules.cmake or a configuration file for package extra-cmake-modules. Adjust CMAKE_MODULE_PATH to find Findextra-cmake-modules.cmake or set extra-cmake-modules_DIR to the directory containing a CMake configuration file for extra-cmake-modules. The file will have one of the following names: extra-cmake-modulesConfig.cmake extra-cmake-modules-config.cmake -- modules path: -- CMake Error at CMakeLists.txt:13 (ecm_use_find_modules): Unknown CMake command ecm_use_find_modules. -- Configuring incomplete, errors occurred! make: *** [rebuild_cache] Error 1 I see several issues here, sorted by importance: 1) the user doesn't know whether his build was supposed to use a Find-module or whether it was supposed to find the Config.cmake file. Especially since there is no file present which tells him that. With Find-modules he can have a look at the Find-module and he will see which header or library cmake is looking for. In the case of a missing Config.cmake file this is not possible. This is IMO a major problem. The user has no chance to guess which file he should look for, and where it should come from: FindFoo.cmake, FooConfig.cmake or Foo-config.cmake. 2) the first thing the error message recommends is to adjust CMAKE_MODULE_PATH. But probably either Foo is not installed at all, or the user should adjust CMAKE_PREFIX_PATH so Foo can be found. But CMAKE_PREFIX_PATH is not mentioned at all. 3) cmake continues processing the CMakeLists.txt even after the REQUIRED message could not be found. IMO it should fail with FATAL_ERROR. What to do about it ? 3) should be easy to solve by failing differently. I can do that. 1) and 2): What I usually recommend is to use a tiny FindFoo.cmake file which basically contains find_package(FOO NO_MODULE). This way the user can find information what went wrong. But it doesn't seem like everybody is doing this. So it should be enforced or at least always obvious what cmake is searching. So here is my proposal: make find_package() search only for Find-modules by default, and only search for config.cmake files if NO_MODULE was used (maybe add a positive option CONFIG_MODE). If then a config.cmake file was not found, the error message can say definitely whether a Find-module was not found, and CMAKE_MODULE_PATH is wrong, or whether the Config.cmake file was not found, and CMAKE_PREFIX_PATH should be adjusted. Also, by looking at the CMakeLists.txt, the user can see whether a Find-module or a Config.cmake file should be found. I am aware that this is quite a change, but thanks to the policy system it shouldn't be able to break anything. I consider this necessary, to avoid the feeling of helplessness among users because they have no idea what went wrong in cmake's configure step. Comments, objections ? 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] Support for imported targets in CMAKE_REQUIRED_LIBRARIES
On 2/16/2012 6:32 AM, Alexander Neundorf wrote:
Done, and pushed to stage.
I added the prefix cmake_ to the function, and added a test for it.
Looks good, thanks.
However now that I look at the end result I realize that the functionality
is not specific to CMAKE_REQUIRED_LIBRARIES at all. It is a general
conversion from imported targets to raw file paths. Perhaps the name
and interface could be made more general:
include(CMakeExpandImportedTargets)
cmake_expand_imported_targets(result LIBRARIES ${CMAKE_REQUIRED_LIBRARIES})
-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] Support for imported targets in CMAKE_REQUIRED_LIBRARIES
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 6:32 AM, Alexander Neundorf wrote:
Done, and pushed to stage.
I added the prefix cmake_ to the function, and added a test for it.
Looks good, thanks.
However now that I look at the end result I realize that the functionality
is not specific to CMAKE_REQUIRED_LIBRARIES at all. It is a general
conversion from imported targets to raw file paths. Perhaps the name
and interface could be made more general:
include(CMakeExpandImportedTargets)
cmake_expand_imported_targets(result LIBRARIES
${CMAKE_REQUIRED_LIBRARIES})
I can change that if you want it.
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] Bad error message when a package could not be found - make find_package() not search config files by default
On 2/16/2012 8:19 AM, Alexander Neundorf wrote: Comments, objections ? The entire point of find_package's interface is that the caller does not need to care how the package is found, and the actual method used for the find can change under the hood. Ideally every package would provide a package config file in its installation and we would never need Find modules. In that case having the extra keyword in every find_package call would be ugly. If you don't like the error message then you are free to write find_package(Foo NO_MODULE) anywhere you want. Perhaps you can add an alternative keyword so that this can be written find_package(Foo CONFIG) instead for those authors who want to do so. Furthermore if you want to guarantee that a Find module is used then add a mode like find_package(Foo MODULE) so that the command knows that it is an error if FindFoo does not exist in CMAKE_MODULE_PATH. In any of the above modes the error message can be more explicit. It is up to the author of the project to choose to do this. I do not want it to be required. For the default case perhaps the wording can be better than it is now. Currently the wording is trying to cover both the case that the developer of the code is reading it and the case that an end user is reading it while running cmake to build a project. The two cases are very different. This is not the first time we've had to deal with messages that are readable by developers but not by users and vice versa. I wonder if we should introduce some kind of use case mode setting that tells CMake who will be reading the messages. Then they can be tailored more effectively to the context. -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] Making Config.cmake files easier to write
On 2/16/2012 10:15 AM, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: In hindsight that name was poorly chosen. I'd really like to see package in the name because they are package configuration files. Otherwise there is no indication it has anything to do with find_package. Well, it has to do with Config files :-) Okay, so it can have PackageConfig in its name since they are package configuration files. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). include(CMakePackageConfigHelper) # CMakeConfigHelper is ambiguous IMO configure_package_config_file(...) write_basic_config_version_file(...) # no need to change name -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] Bad error message when a package could not be found - make find_package() not search config files by default
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 8:19 AM, Alexander Neundorf wrote:
Comments, objections ?
The entire point of find_package's interface is that the caller
does not need to care how the package is found, and the actual
method used for the find can change under the hood.
Ideally every package would provide a package config file in its
installation and we would never need Find modules. In that case
having the extra keyword in every find_package call would be ugly.
I don't think I agree with this.
It should be easily visible what find_package() is looking for, otherwise you
are completely lost what is missing if find_package() did not find the
package.
If you don't like the error message then you are free to write
find_package(Foo NO_MODULE)
anywhere you want.
I personally do that usually, because I know quite well how it works.
The average developer doesn't do this, because for him it works, he usually
has the package installed, and if it is not found, he knows why, because he is
working on it.
I think it should really be enforced to make explicit if a Config-file is
searched.
People have got used to Find-modules, and now those new Config.cmake files
start to appear, which many developers don't know anything about.
Even more so non-developers which just want to build a package.
If I would try to build some downloaded package which does
find_package(Foo 1.0.0)
and cmake tells me that it couldn't find a FindFoo.cmake and also no
FooConfig.cmake and no Foo-config.cmake, I would basically give up at this
moment. Maybe the developer had wrong assumption when building on his machine,
maybe he had some weird installation where some project had installed a
FindFoo.cmake into a directory searched by cmake, if CMAKE_MODULE_PATH is set
up e.g. from an environment variable:
set(CMAKE_MODULE_PATH $ENV{MY_CMAKE_MODULE_DIR} )
or something.
This is not too far fetched, there are emails from time to time how to set up
such a directory so that Find-modules can be shared.
Let's make cmake more strict, to avoid confusion and to make clearer what is
going on.
Perhaps you can add an alternative keyword so
that this can be written
find_package(Foo CONFIG)
instead for those authors who want to do so. Furthermore if you
want to guarantee that a Find module is used then add a mode like
find_package(Foo MODULE)
so that the command knows that it is an error if FindFoo does not
exist in CMAKE_MODULE_PATH.
In any of the above modes the error message can be more explicit.
It is up to the author of the project to choose to do this. I do
not want it to be required.
Here we disagree. I think it should be required, to avoid the impression
finding packages with cmake is a total mess among users who don't know the
details of cmake package searching.
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] Making Config.cmake files easier to write
On Thursday 16 February 2012, Brad King wrote: On 2/16/2012 10:15 AM, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: In hindsight that name was poorly chosen. I'd really like to see package in the name because they are package configuration files. Otherwise there is no indication it has anything to do with find_package. Well, it has to do with Config files :-) Okay, so it can have PackageConfig in its name since they are package configuration files. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). include(CMakePackageConfigHelper) # CMakeConfigHelper is ambiguous IMO configure_package_config_file(...) write_basic_config_version_file(...) # no need to change name Ok, so we have 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file()+ write_basic_config_version_file() 3) configure_package_file()+ write_basic_package_version_file() 4) configure_package_config_file() + write_basic_config_version_file() 5) configure_package_config_file() + write_basic_package_version_file() 6) configure_package_config_file() + write_basic_package_config_version_file() My choice would be: 1), 5), 6), 3), 4), 2) So, 5) ? 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] Making Config.cmake files easier to write
On 2/16/2012 10:48 AM, Alexander Neundorf wrote: 5) configure_package_config_file() + write_basic_package_version_file() So, 5) ? Looks good. Thanks. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
On 2/16/2012 10:30 AM, Alexander Neundorf wrote: In any of the above modes the error message can be more explicit. It is up to the author of the project to choose to do this. I do not want it to be required. Here we disagree. I think it should be required, to avoid the impression finding packages with cmake is a total mess among users who don't know the details of cmake package searching. I'm not opposed to trying to make the messages easier to understand, but I do not want to require every project to change almost every find_package call and generate a policy warning about every call in every old project release. As I said in the part of my message you did not quote in the response the problem is the error message does not know who is reading it. If we can solve that problem then we can make the message say what the reader needs to see. -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] Making Config.cmake files easier to write
On Thu, Feb 16, 2012 at 10:52 AM, Brad King brad.k...@kitware.com wrote: On 2/16/2012 10:48 AM, Alexander Neundorf wrote: 5) configure_package_config_file(**) + write_basic_package_version_** file() So, 5) ? Looks good. Thanks. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Sorry to be a latecomer to the conversation here, but is anybody else concerned about potential confusion between PackageConfig and PkgConfig? -- 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] FYI: Cross compiling ideas...
Hi, just FYI some input on what people would like to have when cross compiling. Like uploading executables to the target in try_run(), installing to a target using something like scp, etc. Alex -- Forwarded Message -- Date: Thursday 16 February 2012, 14:32:21 From: Thomas Zander zan...@kde.org To: neund...@kde.org, Aaron J. Seigo ase...@kde.org torsdagen den 16 februari 2012 12.34.16 skrev Alexander Neundorf: one thought about build systems and remote installation that i'll bounce off of you on irc or by email ... Like make install should do scp or something ? This is too off-topic for ev-membership; but wanted to comment on this anyway. Qt has a tool called 'runonphone' for symbian. Its a piece of crap, but the idea is awesome. you call this thing with a sis file (we would use deb or rpm) and the tool copies it to the device, installs (/replaces) it and starts it. Its always started in debugging mode (i.e. gdb) and printf/qdebug go over the wire to the stdout of runonphone (running on the host machine). I know the berlin guys went further and allowed remote debugging in creator, personally I never saw this, but why not :) If you ever developed for android on eclipse you get some idea about the set of features that would be useful here. Thanks for reading! Sorry for rant ;) -- Thomas Zander - -- 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] target_include_directories branch in stage
Pushed down the queue again... I'll get to it soon. There are a handful of minor changes that I still need to make first. On Thu, Feb 16, 2012 at 8:20 AM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: Excellent : thanks very much for trying it out. I'll try to get this first draft merged to 'next' tonight or tomorrow. Any update on this? -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 1:24 PM, Alexander Neundorf wrote: Actually I expected I would prefer this over the fixed names, but now that I've done it and look at what Config.cmake.in file I have to write, I think I liked the previous version with the fixed names (CONFIG_HELPER) better. I think it was easier to do, a simple scheme. I think the fixed names are better/simpler too. I'm not fond of CONFIG_HELPER specifically. The information stored in them is about the *package* that the file is configuring, which is why I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR is where the *package* goes, not where the config helper is/goes. It's also the same as the package version file input/output variable names. -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] ninja broken on windows?
On 16.02.2012 04:51, Bill Hoffman wrote: On 2/15/2012 5:52 PM, Peter Kümmel wrote: In summary: - use the CMakeLists.txt from https://github.com/syntheticpp/ninja/tree/cmake - on Windows use ninja from https://github.com/syntheticpp/ninja/tree/token-splitter and wait and see what happens with official ninja I can live without the CMakeLists.txt to build ninja. The python thing works pretty easy. However, having to pull different clones of ninja to test for Windows ninja cmake builds is an issue. What are the chances of this being accepted upstream? Are there objections? They are not interested. There is another patch in the pipeline but with this the current generator doesn't work. Use the official ninja and drop Win atm. 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-developers] Making Config.cmake files easier to write
On 2/16/2012 3:29 PM, Eric Noulard wrote: What are you targeting? install-time i.e. make install usage? package install time prodduced with cpack usage? package install time NOT produced with cpack usage? a subset of this? The goal is a FooConfig.cmake file for make install time but that contains no hard-coded paths referring to the install prefix. It should be totally relocatable. I think we've resolved all that in the other parts of this thread. -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] ninja broken on windows?
On 2/16/2012 2:57 PM, Peter Kümmel wrote: They are not interested. There is another patch in the pipeline but with this the current generator doesn't work. Use the official ninja and drop Win atm. Bummer. I am most interested in windows. Would love to stop using gmake... Seems like they are doing lots of stuff with .d files for windows. So, they seem interested in supporting the platform. Is there something we can change in the cmake generator to make it work with the way ninja is today, and will be for the foreseeable future? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 3:29 PM, Eric Noulard wrote:
What are you targeting?
install-time i.e. make install usage?
package install time prodduced with cpack usage?
package install time NOT produced with cpack usage?
a subset of this?
The goal is a FooConfig.cmake file for make install time but
that contains no hard-coded paths referring to the install prefix.
It should be totally relocatable. I think we've resolved all
that in the other parts of this thread.
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
computed by CONFIGURE_CONFIG_FILE with
if(NOT IS_ABSOLUTE ${CCF_INSTALL_DESTINATION})
set(absInstallDir ${CMAKE_INSTALL_PREFIX}/${CCF_INSTALL_DESTINATION})
endif()
file(RELATIVE_PATH CONFIG_RELATIVE_PATH ${absInstallDir}
${CMAKE_INSTALL_PREFIX} )
where you can see the usage of CMAKE_INSTALL_PREFIX.
since CPack is using DESTDIR in order to do its local install before
actual packaging
I cannot see how this could work with CPack but again I may be simply
missing the point
I'll try to follow the thread tomorrow and try by myself.
--
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] Making Config.cmake files easier to write
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.comwrote:
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 3:29 PM, Eric Noulard wrote:
What are you targeting?
install-time i.e. make install usage?
package install time prodduced with cpack usage?
package install time NOT produced with cpack usage?
a subset of this?
The goal is a FooConfig.cmake file for make install time but
that contains no hard-coded paths referring to the install prefix.
It should be totally relocatable. I think we've resolved all
that in the other parts of this thread.
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
computed by CONFIGURE_CONFIG_FILE with
if(NOT IS_ABSOLUTE ${CCF_INSTALL_DESTINATION})
set(absInstallDir ${CMAKE_INSTALL_PREFIX}/${CCF_INSTALL_DESTINATION})
endif()
file(RELATIVE_PATH CONFIG_RELATIVE_PATH ${absInstallDir}
${CMAKE_INSTALL_PREFIX} )
where you can see the usage of CMAKE_INSTALL_PREFIX.
since CPack is using DESTDIR in order to do its local install before
actual packaging
I cannot see how this could work with CPack but again I may be simply
missing the point
I'll try to follow the thread tomorrow and try by myself.
--
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
It can't work with CPack, not in the sense of work as in the software
will run from its DESTDIR-based intermediate CPack driven install location
However, it is a correct config file that will work when an end user
installs it from an rpm or a deb package. (Or an NSIS installer on
Windows...) In fact, it will work regardless of where they install it.
Remember, these config files should not actually be processed by anything
when they are in that DESTDIR CPack install tree, though.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
[snip]
It can't work with CPack, not in the sense of work as in the
software will run from its DESTDIR-based intermediate CPack
driven install location
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded. It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.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] ninja broken on windows?
On 16.02.2012 21:38, Bill Hoffman wrote: On 2/16/2012 2:57 PM, Peter Kümmel wrote: They are not interested. There is another patch in the pipeline but with this the current generator doesn't work. Use the official ninja and drop Win atm. Bummer. I am most interested in windows. Would love to stop using OK, I could update my branch with the official one, disable all Windows specific patches on Linux. This way, testing on Linux is like testing against the official ninja, and an Windows we have intermediate version until ninja supports win32. But I don't wanna touch the generator atm because I don't like the actual proposal for response file support. gmake... Seems like they are doing lots of stuff with .d files for windows. So, they seem interested in supporting the platform. Is there something we can change in the cmake generator to make it work with the way ninja is today, and will be for the foreseeable future? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://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
Re: [cmake-developers] ninja broken on windows?
What are we trying to accomplish here? I have set up 3 of my machines (1 each MacOSX, FreeBSD, and Linux --- like my housekeeper, I don't do Windows) to submit nightly builds using the Ninja generator. That will test the impact of changes in the generator. But it appears that we may also need to be testing the evolving state of ninja. For that, it would seem that we need a different dashboard and (at least as a wrapper) a CMake driven build of ninja. Am I missing something? Richard On Feb 16, 2012, at 3:46 PM, Peter Kümmel wrote: On 16.02.2012 21:38, Bill Hoffman wrote: On 2/16/2012 2:57 PM, Peter Kümmel wrote: They are not interested. There is another patch in the pipeline but with this the current generator doesn't work. Use the official ninja and drop Win atm. Bummer. I am most interested in windows. Would love to stop using OK, I could update my branch with the official one, disable all Windows specific patches on Linux. This way, testing on Linux is like testing against the official ninja, and an Windows we have intermediate version until ninja supports win32. But I don't wanna touch the generator atm because I don't like the actual proposal for response file support. gmake... Seems like they are doing lots of stuff with .d files for windows. So, they seem interested in supporting the platform. Is there something we can change in the cmake generator to make it work with the way ninja is today, and will be for the foreseeable future? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja broken on windows?
On Thu, Feb 16, 2012 at 5:08 PM, Richard Wackerbarth rich...@nfsnet.orgwrote: What are we trying to accomplish here? 2 things: (1) Keep the CMake ninja generator working with the changing state of the CMake code base (primary) (2) Understanding what version of ninja works good on all the platforms on which it is built If we're going to recommend ninja to people because it's better than make in some respects, then we want to have a good understanding of where it works well and where it still has rough edges. Having CMake dashboards using the ninja generator and some build of ninja on as many platforms as possible will help us (as a community) learn these things. Plus, if we have nightly dashboards reporting the status, it's a good place to point people to if they have doubts. I have set up 3 of my machines (1 each MacOSX, FreeBSD, and Linux --- like my housekeeper, I don't do Windows) to submit nightly builds using the Ninja generator. That will test the impact of changes in the generator. Thanks -- these are going to be an excellent addition. But it appears that we may also need to be testing the evolving state of ninja. For that, it would seem that we need a different dashboard and (at least as a wrapper) a CMake driven build of ninja. Ideally, we would have both. Some CMake dashboard submissions built using a known stable-ish ninja, and then some more that use a bleeding edge ninja since it's still in a fairly active stage of development. Am I missing something? Nope. You're spot on. Thanks, Richard. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja broken on windows?
On 2/16/2012 5:19 PM, David Cole wrote: On Thu, Feb 16, 2012 at 5:08 PM, Richard Wackerbarth rich...@nfsnet.org mailto:rich...@nfsnet.org wrote: What are we trying to accomplish here? 2 things: (1) Keep the CMake ninja generator working with the changing state of the CMake code base (primary) (2) Understanding what version of ninja works good on all the platforms on which it is built I just created a ctest script that will pull a clean ninja from git://github.com/martine/ninja.git, build ninja, then use that ninja to run a dashboard of CMake. I did find out that the ninja generator is not part of the cmake bootstrap. So, that test can not run. We might want to add that feature. I am on the fence on that one. We could just disable the test like we do for Xcode. Anyway the script (work in progress) is here: http://www.cdash.org/CDash/viewNotes.php?buildid=2012841 In the nightly section of CMake: http://www.cdash.org/CDash/index.php?project=CMake The results are here: exarius-linux.kitware Linux64-ninja Summary here: http://www.cdash.org/CDash/buildSummary.php?buildid=2012841 -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Modifying RPATH feature to run tests uninstalled
Hi there, One of the macros we have in KDE creates shell scripts to initialize environment variables needed on various platforms so that tests can be run before installation. If RPATH is enabled, the scripts are not needed, but RPATH is sometimes disabled, so the scripts are the solution to that. With the modularization of kdelibs into KDE frameworks (multiple independent pieces), we wondered what to do with that macro and how we can retain its features easily after making kdelibs non-monolithic. I chatted with debian packager Sune Vuorela this evening about this. The linked thread is long and contains long emails, so all of the context is in the IRC log. steveire svuorela: ping? steveire I'm wondering about debian packages. steveire Is it normal to run tests before installing them? steveire Grep for 'Sune' here: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=201 svuorela steveire: it depends on the package. we aren't running kdelibs tests, but we are running libc tests steveire svuorela: And do you run them before installation? svuorela steveire: I think so yes. but even if run after installation it is in a weird prefix (DESTDIR) steveire By coincidence I got an email yesterday from bricks (who packages Grantlee) and he was asking about running tests before installation. He hit the issue in that thread for the exact reason that is there (ie debian disabled RPATH). Is that the 'normal' way to run tests in debian packaging systems? svuorela steveire: so even if RPATH was set you coulddn't easily actually find the installed bits ... steveire ... if the install location isn't already in LD_LIBRARY_PATH? svuorela ...but as a normal user, I would expect that make intsall is something I run after a succsessfull make test steveire svuorela: What do you think of Alex' suggestion? Or should CMAKE_SKIP_RPATH only disable the RPATH for the install tree ? steveire Debian packagers still wouldn't allow the RPATH to be used in the binary dir, would they? steveire So it still wouldn't be possbile to run them uninstalled? svuorela at least from a debian pov, it is the installed version of things that matters. if there is a intermediate RPATH at a stage during compilation no one would care. svuorela and I actually think that it makes quite good sense to have RPATH on during compilation steveire Right, which is why kde creates wrapper scripts to run unit tests with env vars set to find the libraries. steveire It looks like this is the most likely solution: http://www.mail- archive.com/cm...@cmake.org/msg12056.html What do you think? steveire We could add LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/PATH in a command like that. svuorela steveire: I think it makes good sense both to have RPATHs in the build tree (and strip them on install if -DCMAKE_SKIP_RPATH) and to have a way of setting env vars for make test steveire svuorela: Ok, do you mind if I post some of this discussion to the cmake-developers list? svuorela steveire: feel free. So the suggestion is a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but not when building (I don't know if that's easy in CMake), or alternatively provide another CMAKE_ variable to do that. b) Implement something like: set_property(TARGET foo APPEND PROPERTY TEST_ENVIRONMENT foo=bar) Possibly both a) and b). Thoughts/comments? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
Actually I expected I would prefer this over the fixed names, but now
that I've done it and look at what Config.cmake.in file I have to write,
I think I liked the previous version with the fixed names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Alex
# set the version of myself
set(BAR_VERSION_MAJOR @BAR_VERSION_MAJOR@)
set(BAR_VERSION_MINOR @BAR_VERSION_MINOR@)
set(BAR_VERSION_PATCH @BAR_VERSION_PATCH@)
set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} )
@PACKAGE_HELPER_INIT@
set_and_check(BAR_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
set_and_check(BAR_BIN_DIR @PACKAGE_HELPER_BIN_INSTALL_DIR@)
set(BAR_DATA_DIR@PACKAGE_HELPER_DATA_INSTALL_DIR@)
set(BAR_BAR_DIR @PACKAGE_HELPER_BAR_INSTALL_DIR@)
set(BAR_FOO_DIR @PACKAGE_HELPER_FOO_INSTALL_DIR@)
# what is my include directory
set(BAR_INCLUDES ${BAR_INCLUDE_DIR})
# import the exported targets
include(${CMAKE_CURRENT_LIST_DIR}/BarTargets.cmake)
# set the expected library variable
set(BAR_LIBRARIES bar )
--
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] Making GUI applications by default
Hi there, Also in this thread one of the discussion topics was making CMake default to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or MACOSX_BUNDLE property on the executable target. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005 By default CMake does not set those properties, which is actually uncommon. Generally in KDE at least, only unit tests and some small utilities are non- gui executables. We'd like to be able to specify with a defaultProperty something like set(CMAKE_CREATE_GUI_EXECUTABLES ON) which would set those target properties to True on the Windows and Mac platforms by default. For unit tests, we could then disable it again. Thoughts/comments? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
I'm not convinced, yet I'll have to try with the example provided by
Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
[snip]
It can't work with CPack, not in the sense of work as in the
software will run from its DESTDIR-based intermediate CPack
driven install location
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded.
Yes right I got that, my point was that the /../../../
which was computed at configure time was computed w.r.t. CMAKE_INSTALL_PREFIX
know at CMake-time.
It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.cmake.
Right I did not realize that relative position should still be valid.
In fact I'm pretty sure you can break this if you mess-up with
absolute install destination, but if ones to that there is no point in using
this so...
Ok thank you (and David) for enlighting me on this.
--
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
