[cmake-developers] [CMake 0014381]: Inconsistent behaviour between find_package and pkg_check_modules
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14381 == Reported By:JussiP Assigned To: == Project:CMake Issue ID: 14381 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-08-29 03:52 EDT Last Modified: 2013-08-29 03:52 EDT == Summary:Inconsistent behaviour between find_package and pkg_check_modules Description: Find_package and pkg_check_modules behave differently with regard to the REQUIRED keyword. Find_package halts immediately with an error, but pkg_check_modules does not. The entire point of REQUIRED is to halt the configuration if something can't be found. Having the user check the return code by themselves is equivalent to not having the REQUIRED keyword at all. Please change the behaviour of pkg_check_modules to exit on error when REQUIRED is defined. Steps to Reproduce: Run this: --- project(depdemo C) cmake_minimum_required(VERSION 2.8.1) find_package(PkgConfig REQUIRED) pkg_check_modules(DEPS REQUIRED notexisting) message(STATUS This should never be printed.) --- The message text is printed even though it should not be. == Issue History Date ModifiedUsername FieldChange == 2013-08-29 03:52 JussiP New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LIBRARY target type
Stephen Kelly wrote: Hi there, I've rebased and pushed the INTERFACE_LIBRARY-target-type branch to my clone again. See also proof of concept here: https://github.com/purpleKarrot/BoostCMake/pull/1 which is the ongoing work to use CMake for boost using ALIAS targets, INTERFACE targets, EXPORT_NAME, usage requirements etc. It allows this to 'just work': cmake_minimum_required(VERSION 2.8.11) # 2.8.13 project(Test) find_package(BoostAny REQUIRED) add_executable(someexe main.cpp) target_link_libraries(someexe boost::any) For boost, a few more interesting INTERFACE features will be needed eventually, but one step at a time... :) 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] c++ feature detection and usage requirements
On 08/28/2013 10:29 AM, Stephen Kelly wrote:
at least parts of KWIML should fit into this discussion too
[snip]
If instead projects distribute their own copies then we have
the option of changing the API and it is up to them to deal with it when
updating.
Yes. That's what I propose too.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
)
Not quite. A newer CMake would have to write a compatible header
from this command. The current design of KWSys and KWIML is that
their source should be directly copied into the project source
(perhaps with various scripts to run updates). We can change them
as much as we want and projects will decide when they can update.
Each version of their source only has to work with one version
of the library. With an interface like the above many versions
of CMake would have to work with the same version of the project
source.
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still knowing how to generate the old
version. The version argument must be required.
Rather than a single versioned header we should also consider
asking the caller to list the information and features needed.
That way a project can expose a header without more information
than they want to support.
-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] c++ feature detection and usage requirements
Brad King wrote:
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still knowing how to generate the old
version. The version argument must be required.
Ok, I see what you mean.
Another option would be not to have the VERSION in the signature, but always
use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary being
run, so it relieves users of the need to additionally maintain the VERSION
here and figure out how that maps to their minimum cmake version.
Rather than a single versioned header we should also consider
asking the caller to list the information and features needed.
That way a project can expose a header without more information
than they want to support.
Yes, good idea.
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] c++ feature detection and usage requirements
On 08/29/2013 11:14 AM, Stephen Kelly wrote: Another option would be not to have the VERSION in the signature, but always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate. The content generated depends only on the features of the cmake binary being run, so it relieves users of the need to additionally maintain the VERSION here and figure out how that maps to their minimum cmake version. A project may wish to update to a newer required CMake version for some other feature but is not ready to port their header generation. We could define the versions w.r.t. the CMake version and make VERSION optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED. We also need a plan to phase out support for ancient versions in the future. -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
