[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
Re: [CMake] How to have a static/shared option in a Find script ?
Hello again, A short question about your proposal : Michael Hertling wrote (4) DIM_USE_STATIC decides if DIM_LIBRARIES receives DIM_STATIC_LIBRARY or DIM_SHARED_LIBRARY, and because DIM_LIBRARIES is not cached, it can be set anew each time FIND_PACKAGE(DIM ...) is called, so the issue you report on will go away. Why use DIM_USE_STATIC here, and not DIM_FIND_COMPONENTS ? I would think that we get rid of DIM_USE_STATIC if we use components. Cheers, Barth -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-have-a-static-shared-option-in-a-Find-script-tp7287655p7290513.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to have a static/shared option in a Find script ?
Hi again, I have understood what you meant :) For records here is what I did : Thank you again for your supprot, Best regards, Barth -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-have-a-static-shared-option-in-a-Find-script-tp7287655p7291050.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to have a static/shared option in a Find script ?
Hi again,
I have understood what you meant :)
For records here is what I did :
# (1) Use FIND_LIBRARY() to look for the shared and the static library
# and define DIM_SHARED_LIBRARY and DIM_STATIC_LIBRARY in the cache.
find_library(DIM_STATIC_LIBRARY NAMES libdim.a PATHS $ENV{DIMDIR}
PATH_SUFFIXES linux)
find_library(DIM_SHARED_LIBRARY NAMES dim PATHS $ENV{DIMDIR} PATH_SUFFIXES
linux)
# (2) Inspect DIM_FIND_COMPONENTS to see which flavor has been requested,
# defaulting to shared if no components have been requested at all.
LIST(FIND DIM_FIND_COMPONENTS static ASK_STATIC_COMP)
LIST(FIND DIM_FIND_COMPONENTS shared ASK_SHARED_COMP)
# (3) Warn or bail out if shared and static have both been requested
if ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
message(WARNING Two incompatible components specified : static and
shared. We are going to ignore the static component.)
endif ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
# (4) DIM_USE_STATIC decides if DIM_LIBRARIES receives DIM_STATIC_LIBRARY
# or DIM_SHARED_LIBRARY
option(DIM_FORCE_STATIC Turn on to force the use of the static library
OFF)
if( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_STATIC_LIBRARY} )
else ( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_SHARED_LIBRARY} )
endif( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
Thank you again for your supprot,
Best regards,
Barth
--
View this message in context:
http://cmake.3232098.n2.nabble.com/How-to-have-a-static-shared-option-in-a-Find-script-tp7287655p7291064.html
Sent from the CMake mailing list archive at Nabble.com.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to have a static/shared option in a Find script ?
On 02/16/2012 03:14 PM, Barth wrote:
Hi again,
I have understood what you meant :)
Hhm, actually, I talked nonsense w.r.t. DIM_USE_STATIC. ;)
For records here is what I did :
# (1) Use FIND_LIBRARY() to look for the shared and the static library
# and define DIM_SHARED_LIBRARY and DIM_STATIC_LIBRARY in the cache.
find_library(DIM_STATIC_LIBRARY NAMES libdim.a PATHS $ENV{DIMDIR}
PATH_SUFFIXES linux)
find_library(DIM_SHARED_LIBRARY NAMES dim PATHS $ENV{DIMDIR} PATH_SUFFIXES
linux)
If libdim.so doesn't exist, but libdim.a does, the last FIND_LIBRARY()
call would return libdim.a, too, which is probably not desired. Here,
one should consider to narrow the search for the respective library
type, e.g. by manipulating CMAKE_FIND_LIBRARY_SUFFIXES; see also
CMAKE_{SHARED,STATIC}_LIBRARY_{PREFIX,SUFFIX} in this regard.
# (2) Inspect DIM_FIND_COMPONENTS to see which flavor has been requested,
# defaulting to shared if no components have been requested at all.
LIST(FIND DIM_FIND_COMPONENTS static ASK_STATIC_COMP)
LIST(FIND DIM_FIND_COMPONENTS shared ASK_SHARED_COMP)
No need for them; use DIM_FIND_REQUIRED_{STATIC,SHARED} - predefined
by FIND_PACKAGE(). Refer to Modules/readme.txt for more information.
# (3) Warn or bail out if shared and static have both been requested
if ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
message(WARNING Two incompatible components specified : static and
shared. We are going to ignore the static component.)
endif ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
IF(DIM_FIND_REQUIRED_SHARED AND DIM_FIND_REQUIRED_STATIC)
MESSAGE(WARNING ...)
LIST(REMOVE_ITEM DIM_FIND_COMPONENTS static)
UNSET(DIM_FIND_REQUIRED_STATIC)
ENDIF()
Do something to the contrary if DIM_FIND_COMPONENTS is empty:
IF(NOT DIM_FIND_COMPONENTS)
LIST(APPEND DIM_FIND_COMPONENTS shared)
SET(DIM_FIND_REQUIRED_SHARED TRUE)
ENDIF()
The point is that DIM_FIND_COMPONENTS and DIM_FIND_REQUIRED_* are set
up properly *before* you are going to actually enable the components.
# (4) DIM_USE_STATIC decides if DIM_LIBRARIES receives DIM_STATIC_LIBRARY
# or DIM_SHARED_LIBRARY
option(DIM_FORCE_STATIC Turn on to force the use of the static library
OFF)
if( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_STATIC_LIBRARY} )
else ( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_SHARED_LIBRARY} )
endif( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
UNSET(DIM_INCLUDE_DIRS)
UNSET(DIM_LIBRARIES)
SET(DIM_FOUND FALSE)
FIND_PATH(DIM_INCLUDE_DIR ...)
IF(DIM_INCLUDE_DIR)
SET(DIM_FOUND TRUE)
ENDIF
IF(DIM_FIND_REQUIRED_SHARED)
FIND_LIBRARY(DIM_SHARED_LIBRARY ...)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(
DIM_SHARED
DEFAULT_MSG
DIM_INCLUDE_DIR
DIM_SHARED_LIBRARY)
IF(DIM_SHARED_FOUND)
LIST(APPEND DIM_INCLUDE_DIRS ${DIM_INCLUDE_DIR} ...)
LIST(APPEND DIM_LIBRARIES ${DIM_SHARED_LIBRARY} ...)
ENDIF()
LIST(REMOVE DIM_FIND_COMPONENTS shared)
UNSET(DIM_FIND_REQUIRED_SHARED)
ENDIF()
IF(DIM_FIND_REQUIRED_STATIC)
FIND_LIBRARY(DIM_STATIC_LIBRARY ...)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(
DIM_STATIC
DEFAULT_MSG
DIM_INCLUDE_DIR
DIM_STATIC_LIBRARY)
IF(DIM_STATIC_FOUND)
LIST(APPEND DIM_INCLUDE_DIRS ${DIM_INCLUDE_DIR} ...)
LIST(APPEND DIM_LIBRARIES ${DIM_STATIC_LIBRARY} ...)
ENDIF()
LIST(REMOVE DIM_FIND_COMPONENTS static)
UNSET(DIM_FIND_REQUIRED_STATIC)
ENDIF()
# Consider to handle remaining components in DIM_FIND_COMPONENTS.
Note that due to the preparatory work on DIM_FIND_COMPONENTS and the
DIM_FIND_REQUIRED_* variables, the blocks for enabling the shared and
static component have a straight forward structure. Note further that
this can be achieved only with a quite simple package like yours with
two mutually exclusive libraries; with packages providing more subtly
related components - e.g. with inter-component dependencies - things
can be much more complicated. Note finally that the user must issue
IF(DIM_FOUND AND DIM_SHARED_FOUND)
e.g., in order to check for the library's availability unless the
REQUIRED flag was given to FIND_PACKAGE(). Checking for DIM_FOUND
or DIM_SHARED_FOUND alone is *not* reliable, just as referring to
a component that hasn't been requested explicitly - or enabled by
default which, in turn, should be documented explicitly.
Regards,
Michael
--
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] On WINDOWS, Is it Possible to build 64-bit and 32-bit Solutions in One Go?
On Thu, Feb 16, 2012 at 2:54 PM, Hashim Mir h...@rim.com wrote: Hi, This is what I am doing presently in order to compile both a 32-bit and a 64-bit version of my project: cmake.exe -G “Visual Studio 9 2008” #for x32 cmake.exe -G “Visual Studio 9 2008 Win64” #for x64 Is it possible to consolidate the two individual statements into one somehow, in order to compile both 32 and 64 bit configurations of my project files with one command? No. CMake does not allow this. Only 1 generator can exist for a solution. John -- 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] On WINDOWS, Is it Possible to build 64-bit and 32-bit Solutions in One Go?
On Thu, Feb 16, 2012 at 3:27 PM, John Drescher dresche...@gmail.com wrote: On Thu, Feb 16, 2012 at 2:54 PM, Hashim Mir h...@rim.com wrote: Hi, This is what I am doing presently in order to compile both a 32-bit and a 64-bit version of my project: cmake.exe -G “Visual Studio 9 2008” #for x32 cmake.exe -G “Visual Studio 9 2008 Win64” #for x64 Is it possible to consolidate the two individual statements into one somehow, in order to compile both 32 and 64 bit configurations of my project files with one command? No. CMake does not allow this. Only 1 generator can exist for a solution. And I mean in the same build folder tree. You can however make 2 build folder trees and use a batch file to have both build separately at the same time from the command prompt. John -- 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] message could not create named generator CodeBlocks -MinGW Makefiles
Hello,I am trying to use CMake with codeblocks on windows, I created a simple project in the folder pCMakewhen I use the CMake interface I got the message:CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.and following the tutorial from florian-goujeon (CMake,CodeBlock), it's advise to execute a cmake --help from a console in the project folder in order to get the generator listcodeblocks -MinGW Makefiles is listed but when I executecMake . -G"CodeBlocks -MinGW Makefiles" I get also the following messageCMake Error:could not create names generator CodeBlocks -MinGW MakefilesI installed codeblocks with the windows installer with gcc compiler and cmake with the windows installerI don't know what to do, any suggestions will be very helpful -- 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] find both shared and static versions?
I have an application where I want to link some targets against shared
versions of Boost and some against static versions.
(I'd prefer shared in general, but I need to link against the static
version of boost for my matlab mex interface, to avoid loading the
different version of boost shipped by matlab on runtime. I'm using this
approachhttps://github.com/mariusmuja/flann/blob/master/src/matlab/CMakeLists.txtof
a custom target calling the mex command to compile the mex file.)
FindBoost.cmake honors the Boost_USE_STATIC_LIBS variable, but that doesn't
quite solve it.
I've had the following ideas, none of which I'm happy with:
1. Use -L${Boost_LIBRARY_DIRS} and then construct the name by doing a
string replacement from .so/.dylib to .a in ${Boost_THREAD_LIBRARY}.
Definitely won't work on Windows, might not work for some types of Boost
installations on Linux/Mac, and fails at link-time instead of
configure-time if the static version doesn't exist. Maybe there's an
equivalent transformation that'll probably work on Windows; I don't know,
I'm not a Windows user.
2. Copy FindBoost.cmake to FindBoostS.cmake and replace all the
variables to use a BoostS prefix, as well as making the conditionals for
USE_STATIC_LIBS always be on; then I can run find_package(Boost) as well as
find_package(BoostS).
3. There might be some trickery to approximate (2) without actually
modifying FindBoost, but I haven't figured it out.
4. Modify FindBoost.cmake either to look for both dynamic and shared
libraries and set e.g. Boost_THREAD_LIBRARY_STATIC and
Boost_THREAD_LIBRARY_SHARED if found, or to add shared and static versions
for each component, as in
http://www.cmake.org/pipermail/cmake/2012-February/049142.html
(4) is obviously the best approach, but it's also probably much more work
than I really want to do on this.
Any suggestions? Some other approach I haven't thought of, a way to do (3),
a copy of (4) floating around somewhere?
Thanks,
Dougal
--
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] Doesn't anyone know how to get precompiled headers working under CMake for Visual Studio 2010?
My team has been using precompiled headers under CMake and Visual Studio 2008
for quite a while. Now we've switched to VS 2010, the cmake code we used to
support precompiled headers is no longer working.
The following is the code in question and we're just using
set_source_files_properties to add the appropreiate /Yc , /Yu and /FI flags.
It appears, under VS 2010, the property manager is not accepting or over
writing these settings.
Doesn't anyone know how to get precompiled headers working under CMake for
Visual Studio 2010?
IF(EXISTS ${pch_unity})
FILE(READ ${pch_unity} buffer)
ENDIF(EXISTS ${pch_unity})
IF(NOT (${buffer} STREQUAL ${file_contents}))
FILE(WRITE ${pch_unity} ${file_contents})
ENDIF(NOT (${buffer} STREQUAL ${file_contents}))
SET_SOURCE_FILES_PROPERTIES(${pch_unity} PROPERTIES COMPILE_FLAGS
/Yc\${pch_abs}\)
###
#
# Update properties of source files to use the precompiled header.
# Additionally, force the inclusion of the precompiled header at beginning of
each source file.
#
FOREACH(source_file ${srcFilesThatUsePCH} )
SET_SOURCE_FILES_PROPERTIES(
${source_file}
PROPERTIES COMPILE_FLAGS
/Yu\${pch_abs}\ /FI\${pch_abs}\
)
ENDFOREACH(source_file)
###
#
# Finally, update the source file collection to contain the precompiled header
translation unit
#
SET(${FILES_VARIABLE_NAME} ${${FILES_VARIABLE_NAME}} ${pch_unity} PARENT_SCOPE)
++David-Bjornbak;
--
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] Doesn't anyone know how to get precompiled headers working under CMake for Visual Studio 2010?
On Thu, Feb 16, 2012 at 7:39 PM, david_bjorn...@agilent.com wrote:
My team has been using precompiled headers under CMake and Visual Studio
2008 for quite a while. Now we’ve switched to VS 2010, the cmake code we
used to support precompiled headers is no longer working.
The following is the code in question and we’re just using
set_source_files_properties to add the appropreiate /Yc , /Yu and /FI flags.
It appears, under VS 2010, the property manager is not accepting or over
writing these settings.
Doesn’t anyone know how to get precompiled headers working under CMake for
Visual Studio 2010?
IF(EXISTS ${pch_unity})
FILE(READ ${pch_unity} buffer)
ENDIF(EXISTS ${pch_unity})
IF(NOT (${buffer} STREQUAL ${file_contents}))
FILE(WRITE ${pch_unity} ${file_contents})
ENDIF(NOT (${buffer} STREQUAL ${file_contents}))
SET_SOURCE_FILES_PROPERTIES(${pch_unity} PROPERTIES COMPILE_FLAGS
/Yc\${pch_abs}\)
###
#
# Update properties of source files to use the precompiled header.
# Additionally, force the inclusion of the precompiled header at beginning
of each source file.
#
FOREACH(source_file ${srcFilesThatUsePCH} )
SET_SOURCE_FILES_PROPERTIES(
${source_file}
PROPERTIES COMPILE_FLAGS
/Yu\${pch_abs}\ /FI\${pch_abs}\
)
ENDFOREACH(source_file)
###
#
# Finally, update the source file collection to contain the precompiled
header translation unit
#
SET(${FILES_VARIABLE_NAME} ${${FILES_VARIABLE_NAME}} ${pch_unity}
PARENT_SCOPE)
For me I use the same exact macro that I have used since VS 2005.
Attached is the macro and here is an example library that uses the macro.
SET( ${PROJECT_NAME}_SRCS
./src/smException.cxx
./src/smitkIndent.cxx
./src/smState.cxx
./src/smPropertyMap.cxx
./src/smOperation.cxx
./src/smPgmSettings.cxx
./src/smStringList.cxx
./src/smObject.cxx
./src/smAppBase.cxx
./src/smSpawnJob.cxx
./src/smLog.cxx
./src/smBIRADS7.cxx
./src/smErrorBase.cxx
)
SET( ${PROJECT_NAME}_EXT_HDRS
./Include/smException.h
./Include/smitkIndent.h
./Include/smMacros.h
./Include/smPropertyMap.h
./Include/smOperation.h
./Include/smPgmSettings.h
./Include/smStringList.h
./Include/smConstants.h
./Include/smLog.h
./Include/smBIRADS7.h
./Include/smErrorBase.h
)
SET( ${PROJECT_NAME}_MOC_HDRS
./Include/smState.h
./Include/smObject.h
./Include/smAppBase.h
./Include/smSpawnJob.h
)
# some .ui files
SET( ${PROJECT_NAME}_UIS
)
# and finally an resource file
SET( ${PROJECT_NAME}_RCS
)
SET( ${PROJECT_NAME}_INT_HDRS
)
#Add precompiled header support
MSVC_PCH_SUPPORT(${PROJECT_NAME})
# this command will generate rules that will run rcc on all files from
UPMC_LA_RCS
# in result UPMC_LA_RC_SRCS variable will contain paths to files produced by rcc
QT4_ADD_RESOURCES( ${PROJECT_NAME}_RC_SRCS ${${PROJECT_NAME}_RCS} )
# and finally this will run moc:
QT4_WRAP_CPP( ${PROJECT_NAME}_MOC_SRCS ${${PROJECT_NAME}_MOC_HDRS} )
# this will run uic on .ui files:
QT4_WRAP_UI( ${PROJECT_NAME}_UI_HDRS ${${PROJECT_NAME}_UIS} )
IF(BUILD_EXPERIMENTAL)
add_subdirectory(Experimental)
ENDIF(BUILD_EXPERIMENTAL)
include_directories(
${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/..
${PROJECT_SOURCE_DIR}/Include
${STUDY_MANAGER_SRC}/Include
)
add_library(${PROJECT_NAME}
${${PROJECT_NAME}_SRCS}
${${PROJECT_NAME}_EXT_HDRS}
${${PROJECT_NAME}_MOC_HDRS}
${${PROJECT_NAME}_MOC_SRCS}
${${PROJECT_NAME}_INT_HDRS}
${${PROJECT_NAME}_UI_HDRS}
${${PROJECT_NAME}_RC_SRCS}
)
John
MSVCPCHSupport.cmake
Description: Binary data
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2653-g29fe3cb
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 29fe3cbd7d5cb34465203abd4e27dcbe12103bd2 (commit)
via f19149270c0aae1799d4fefe221d1deaf5dd1bad (commit)
from 90e8fa5e9ab590ad7b77cc5eacbe3029f332f8bd (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=29fe3cbd7d5cb34465203abd4e27dcbe12103bd2
commit 29fe3cbd7d5cb34465203abd4e27dcbe12103bd2
Merge: 90e8fa5 f191492
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Thu Feb 16 12:35:39 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 16 12:35:39 2012 -0500
Merge topic 'findlibrary-versioned-libraries' into next
f191492 another try for the versioned find_library test
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f19149270c0aae1799d4fefe221d1deaf5dd1bad
commit f19149270c0aae1799d4fefe221d1deaf5dd1bad
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Thu Feb 16 18:35:17 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Thu Feb 16 18:35:17 2012 +0100
another try for the versioned find_library test
diff --git a/Tests/Complex/CMakeLists.txt b/Tests/Complex/CMakeLists.txt
index 518b475..40de212 100644
--- a/Tests/Complex/CMakeLists.txt
+++ b/Tests/Complex/CMakeLists.txt
@@ -199,7 +199,7 @@ CONFIGURE_FILE(
${Complex_SOURCE_DIR}/Library/dummy
${Complex_BINARY_DIR}/Library/dummylib.lib
COPYONLY IMMEDIATE)
-FOREACH (ext ${CMAKE_SHLIB_SUFFIX};.so;.a;.sl;so.2)
+FOREACH (ext ${CMAKE_SHLIB_SUFFIX};.so;.a;.sl;.so.2)
CONFIGURE_FILE(
${Complex_SOURCE_DIR}/Library/dummy
${Complex_BINARY_DIR}/Library/libdummylib${ext}
---
Summary of changes:
Tests/Complex/CMakeLists.txt |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-2660-gd8d31a6
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 d8d31a644abde62197ba3dad669420e87339a924 (commit) via f4f94f3b7f89f069725668c38d15ffe7526bfe45 (commit) from 9d5a3c5e673956e05bfd662bf6bdef2d29c9fe35 (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=d8d31a644abde62197ba3dad669420e87339a924 commit d8d31a644abde62197ba3dad669420e87339a924 Merge: 9d5a3c5 f4f94f3 Author: David Cole david.c...@kitware.com AuthorDate: Thu Feb 16 17:01:05 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 16 17:01:05 2012 -0500 Merge topic 'suppress-clang-warning' into next f4f94f3 CTestCustom: Suppress clang warning on the dashboard http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4f94f3b7f89f069725668c38d15ffe7526bfe45 commit f4f94f3b7f89f069725668c38d15ffe7526bfe45 Author: David Cole david.c...@kitware.com AuthorDate: Thu Feb 16 16:03:27 2012 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Thu Feb 16 16:03:27 2012 -0500 CTestCustom: Suppress clang warning on the dashboard argument unused during compilation -- well, thanks, but ... If somebody has a fix to eliminate this warning entirely, rather than simply suppressing it from our dashboard results, I'm all ears. diff --git a/CTestCustom.cmake.in b/CTestCustom.cmake.in index 1a46688..c36cee4 100644 --- a/CTestCustom.cmake.in +++ b/CTestCustom.cmake.in @@ -44,6 +44,7 @@ SET(CTEST_CUSTOM_WARNING_EXCEPTION cc-3968 CC: WARNING File.* # implicit truncation by static_cast ld: warning: directory not found for option .-(F|L) warning.*This version of Mac OS X is unsupported + clang.*: warning: argument unused during compilation: .-g # Ignore clang's summary warning, assuming prior text has matched some # other warning expression: --- Summary of changes: CTestCustom.cmake.in |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, next, updated. v2.8.7-2662-gf08963b
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 f08963bf9baf9312ec01ecb8f4eb57486c27083f (commit)
via 43118d04cbb08814fd98e87afeadcfb703277606 (commit)
from d8d31a644abde62197ba3dad669420e87339a924 (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=f08963bf9baf9312ec01ecb8f4eb57486c27083f
commit f08963bf9baf9312ec01ecb8f4eb57486c27083f
Merge: d8d31a6 43118d0
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Feb 16 17:39:44 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 16 17:39:44 2012 -0500
Merge topic 'HandleTargetsInCMakeRequiredLibraries' into next
43118d0 CMakeExpandImportedTargets: add CONFIGURATION parameter
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43118d04cbb08814fd98e87afeadcfb703277606
commit 43118d04cbb08814fd98e87afeadcfb703277606
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Feb 16 23:35:43 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Feb 16 23:35:43 2012 +0100
CMakeExpandImportedTargets: add CONFIGURATION parameter
As pointed out by Brad, now that cmake_expand_imported_targets() is
more generic, hardcoding to use CMAKE_TRY_COMPILE_CONFIGURATION is not
a good idea. So add a CONFIGURATION parameter, which defaults to
CMAKE_CONFIGURATION_TYPES[0] (if set) or CMAKE_BUILD_TYPE otherwise.
Use this with ${CMAKE_TRY_COMPILE_CONFIGURATION} in all the Check*.cmake
files.
Alex
diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
index 88dedeb..fba071a 100644
--- a/Modules/CMakeExpandImportedTargets.cmake
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -1,13 +1,19 @@
-# CMAKE_EXPAND_IMPORTED_TARGETS(var LIBRARIES lib1 lib2...libN)
+# CMAKE_EXPAND_IMPORTED_TARGETS(var LIBRARIES lib1 lib2...libN
+# [CONFIGURATION config] )
#
# CMAKE_EXPAND_IMPORTED_TARGETS() takes a list of libraries and replaces
# all imported targets contained in this list with their actual file paths
# of the referenced libraries on disk, including the libraries from their
# link interfaces.
+# If a CONFIGURATION is given, it uses the respective configuration of the
+# imported targets if it exists. If no CONFIGURATION is given, it uses
+# the first configuration from ${CMAKE_CONFIGURATION_TYPES} if set, otherwise
+# ${CMAKE_BUILD_TYPE}.
# This macro is used by all Check*.cmake files which use
# TRY_COMPILE() or TRY_RUN() and support CMAKE_REQUIRED_LIBRARIES , so that
# these checks support imported targets in CMAKE_REQUIRED_LIBRARIES:
-#cmake_expand_imported_targets(expandedLibs LIBRARIES
${CMAKE_REQUIRED_LIBRARIES} )
+#cmake_expand_imported_targets(expandedLibs LIBRARIES
${CMAKE_REQUIRED_LIBRARIES}
+# CONFIGURATION
${CMAKE_TRY_COMPILE_CONFIGURATION} )
#=
@@ -24,16 +30,31 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
+include(CMakeParseArguments)
-function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT _LIB)
+function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
- if(NOT ${_LIB} STREQUAL LIBRARIES)
- message(FATAL_ERROR cmake_expand_imported_targets() called with bad
second argument \${_LIB}\, expected keyword \LIBRARIES\.)
+ set(options )
+ set(oneValueArgs CONFIGURATION )
+ set(multiValueArgs LIBRARIES )
+
+ cmake_parse_arguments(CEIT ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN})
+
+ if(CEIT_UNPARSED_ARGUMENTS)
+ message(FATAL_ERROR Unknown keywords given to
CMAKE_EXPAND_IMPORTED_TARGETS(): \${CEIT_UNPARSED_ARGUMENTS}\)
+ endif()
+
+ if(NOT CEIT_CONFIGURATION)
+ if(CMAKE_CONFIGURATION_TYPES)
+ list(GET CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION)
+ else()
+ set(CEIT_CONFIGURATION ${CMAKE_BUILD_TYPE})
+ endif()
endif()
# handle imported library targets
- set(_CCSR_REQ_LIBS ${ARGN})
+ set(_CCSR_REQ_LIBS ${CEIT_LIBRARIES})
set(_CHECK_FOR_IMPORTED_TARGETS TRUE)
set(_CCSR_LOOP_COUNTER 0)
@@ -61,7 +82,7 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT _LIB)
# if one of the imported configurations equals
${CMAKE_TRY_COMPILE_CONFIGURATION},
# use it, otherwise simply use the first one:
-list(FIND _importedConfigs ${CMAKE_TRY_COMPILE_CONFIGURATION}
_configIndexToUse)
+list(FIND _importedConfigs ${CEIT_CONFIGURATION}
_configIndexToUse)
[Cmake-commits] CMake branch, next, updated. v2.8.7-2668-gffdef87
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 ffdef8726313f88bcfc534f37a989db8c5b93c47 (commit)
via 4585e573b8dc0473bd1caf56da85d9f6e57f0d8f (commit)
from 4a5d20dd223fa0f831c1c077889032cb7782b0b0 (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=ffdef8726313f88bcfc534f37a989db8c5b93c47
commit ffdef8726313f88bcfc534f37a989db8c5b93c47
Merge: 4a5d20d 4585e57
Author: David Cole david.c...@kitware.com
AuthorDate: Thu Feb 16 18:05:14 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 16 18:05:14 2012 -0500
Merge topic 'findblas-bugs' into next
4585e57 FindBLAS/FindLAPACK: Work with MKL version 10.3 (#12924, #12925)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4585e573b8dc0473bd1caf56da85d9f6e57f0d8f
commit 4585e573b8dc0473bd1caf56da85d9f6e57f0d8f
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Sun Feb 5 18:01:38 2012 +0400
Commit: David Cole david.c...@kitware.com
CommitDate: Thu Feb 16 18:03:08 2012 -0500
FindBLAS/FindLAPACK: Work with MKL version 10.3 (#12924, #12925)
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index 9b76d90..9eadfd1 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -23,6 +23,7 @@
##
### List of vendors (BLA_VENDOR) valid in this module
## Goto,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,Intel10_32
(intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,lp thread model, lp64
model),
+## Intel10_64lp_seq (intel mkl v10 64 bit,sequential code, lp64 model),
## Intel( older versions of mkl 32 and 64 bit), ACML,ACML_MP,ACML_GPU,Apple,
NAS, Generic
# C/CXX should be enabled to use Intel mkl
@@ -85,6 +86,7 @@ if (NOT _libdir)
set(_libdir /usr/local/lib /usr/lib /usr/local/lib64 /usr/lib64 ENV
LD_LIBRARY_PATH)
endif ()
endif ()
+
foreach(_library ${_list})
set(_combined_name ${_combined_name}_${_library})
@@ -115,7 +117,7 @@ foreach(_library ${_list})
endforeach(_library ${_list})
if(_libraries_work)
# Test this combination of libraries.
- set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_threads})
+ set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_thread})
# message(DEBUG: CMAKE_REQUIRED_LIBRARIES = ${CMAKE_REQUIRED_LIBRARIES})
if (_CHECK_FORTRAN)
check_fortran_function_exists(${_name} ${_prefix}${_combined_name}_WORKS)
@@ -460,117 +462,99 @@ if (BLA_VENDOR MATCHES Intel* OR BLA_VENDOR STREQUAL
All)
else(BLAS_FIND_QUIETLY OR NOT BLAS_FIND_REQUIRED)
find_package(Threads REQUIRED)
endif(BLAS_FIND_QUIETLY OR NOT BLAS_FIND_REQUIRED)
- if (WIN32)
+
+ set(BLAS_SEARCH_LIBS )
+
if(BLA_F95)
-if(NOT BLAS95_LIBRARIES)
-check_fortran_libraries(
-BLAS95_LIBRARIES
-BLAS
-sgemm
-
-mkl_blas95;mkl_intel_c;mkl_intel_thread;mkl_core;libguide40
-
-)
-endif(NOT BLAS95_LIBRARIES)
- else(BLA_F95)
-if(NOT BLAS_LIBRARIES)
-check_fortran_libraries(
-BLAS_LIBRARIES
-BLAS
-SGEMM
-
-mkl_c_dll;mkl_intel_thread_dll;mkl_core_dll;libguide40
-
-)
-endif(NOT BLAS_LIBRARIES)
- endif(BLA_F95)
- else(WIN32)
- if (BLA_VENDOR STREQUAL Intel10_32 OR BLA_VENDOR STREQUAL All)
-if(BLA_F95)
- if(NOT BLAS95_LIBRARIES)
- check_fortran_libraries(
- BLAS95_LIBRARIES
- BLAS
- sgemm
-
- mkl_blas95;mkl_intel;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT};${LM}
- )
- endif(NOT BLAS95_LIBRARIES)
-else(BLA_F95)
-if(NOT BLAS_LIBRARIES)
- check_fortran_libraries(
- BLAS_LIBRARIES
- BLAS
- sgemm
-
- mkl_intel;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT}
- ${LM}
- )
- endif(NOT BLAS_LIBRARIES)
-endif(BLA_F95)
- endif (BLA_VENDOR STREQUAL Intel10_32 OR BLA_VENDOR STREQUAL All)
- if (BLA_VENDOR STREQUAL Intel10_64lp OR BLA_VENDOR STREQUAL All)
- if(BLA_F95)
-if(NOT BLAS95_LIBRARIES)
- check_fortran_libraries(
- BLAS95_LIBRARIES
- BLAS
- sgemm
-
- mkl_blas95;mkl_intel_lp64;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT};${LM}
- )
-endif(NOT BLAS95_LIBRARIES)
- else(BLA_F95)
- if(NOT BLAS_LIBRARIES)
+set(BLAS_mkl_SEARCH_SYMBOL SGEMM)
+set(_LIBRARIES BLAS95_LIBRARIES)
+if (WIN32)
+ list(APPEND BLAS_SEARCH_LIBS
+mkl_blas95 mkl_intel_c mkl_intel_thread mkl_core libguide40)
+else (WIN32)
+ if (BLA_VENDOR STREQUAL Intel10_32 OR BLA_VENDOR STREQUAL All)
+list(APPEND BLAS_SEARCH_LIBS
+ mkl_blas95
[Cmake-commits] CMake branch, master, updated. v2.8.7-378-gd03606a
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 d03606a19cc05872baf23269ae8ec61d2e0719e8 (commit) from e2042b68d36e0881bfc00f926a275dda3d6cbc9d (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=d03606a19cc05872baf23269ae8ec61d2e0719e8 commit d03606a19cc05872baf23269ae8ec61d2e0719e8 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Feb 17 00:05:08 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Feb 17 00:05:08 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 1c285d0..c80c53f 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 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 16) +SET(KWSYS_DATE_STAMP_DAY 17) --- 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
