Re: [cmake-developers] Fwd: How to handle different cmake versions in extra-cmake-modules ?
On 11/6/2011 6:12 AM, Stephen Kelly wrote:
ecm_copy_modules(${CMAKE_BINARY_DIR}/modules FindFoo.cmake
FindBlub.cmake
ECMDoSomething.cmake)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_BINARY_DIR}/modules} )
This macro would copy just these needed files into the given directory, which
can then be added to CMAKE_MODULE_PATH.
See below for an idea that may solve cases 2 and 3 together.
Case 3. I don't really have an idea yet. Add some code at the top of each file
which include()s the file from cmake if the version is bigger than some
specified version ?
Something like:
FindBlub.cmake:
if(CMAKE_VERSION 2.8.12)
include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
return()
endif()
We've done the following before:
if(EXISTS ${CMAKE_ROOT}/Modules/FindBlub.cmake)
include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
return()
endif()
That way you don't need to know when the module is added. It is also
forward-compatible for any module not yet in CMake but may be later.
OTOH the version of the module added to CMake may provide a slightly
different interface than the original version. That leads to the
unfortunate situation that a newer CMake breaks an existing build,
which looks like CMake's fault but isn't.
Another option is to provide a function that generates forwarding
modules. Instead of ecm_copy_modules, create a similar API that
generates short modules that include either the ECM version or the
CMake version depending on some conditions. Do the inclusion by
full path so that the actual ECM module dir does not need to be in
the CMAKE_MODULE_PATH.
-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] CMake Git instructions revised (was: Can't push to master directly)
On 11/5/2011 8:48 PM, Stephen Kelly wrote: Could it be an idea to split that page so that there is a page for people like me or new people which doesn't say anything about pushing to master? I've been meaning to update the Git instructions page for a while. The entry point is still here: http://www.cmake.org/Wiki/CMake/Git but it is now a dispatch point mapping typical use cases to dedicated instruction pages. The main developer instructions are now here: http://www.cmake.org/Wiki/CMake/Git/Develop -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] Should sucessive calls to find_package for one package succeed?
Brad King wrote:
On 11/6/2011 7:00 PM, Stephen Kelly wrote:
include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
It is up to the author of the config file to block this correctly
against multiple inclusion, e.g.
if(NOT Grantlee_TARGETS_INCLUDED)
set(Grantlee_TARGETS_INCLUDED 1)
include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
endif()
Ok, thanks. Seems like an important thing to document. Is there any page
showing how to use config files and targets files? I only found out how to
use them by talking to Alex :).
if (NOT TARGET grantlee_templates)
ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
endif()
This would hide cases of accidentally conflicting target names.
I don't understand. You mean if someone called install(EXPORTS) with the
wrong target?
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] Should sucessive calls to find_package for one package succeed?
On 11/7/2011 10:18 AM, Stephen Kelly wrote: Ok, thanks. Seems like an important thing to document. Is there any page showing how to use config files and targets files? http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages This section: http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Packaging_and_Exporting could be updated with that suggestion. if (NOT TARGET grantlee_templates) ADD_LIBRARY(grantlee_templates SHARED IMPORTED) endif() This would hide cases of accidentally conflicting target names. I don't understand. If an application defines a target named foo as part of its own build and then uses find_package to load a dependency that also defines foo then a target-wise blocker like the above will silently skip the imported target. Then the imported dependency won't link correctly because it will use the application's foo instead of the package's foo. We need to allow the add_library command to complain about an existing target. -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] target_include_directories branch in stage
On Sunday 06 November 2011, Stephen Kelly wrote:
Stephen Kelly wrote:
Issues:
* I have only tried to implement this with the makefile generator and
have so far only tested it with Unix Makefiles. One of the bugs says
XCode can't do source-level includes. Can it do target-level includes?
Would I have to implement this for all generators before it would be
considered for acceptance?
* There's scope for refactoring the new code in my branch as well as
potentially refactoring with the cmIncludeDirectoriesCommand.
* There's scope for optimization.
* I haven't written any tests yet.
Related to Alex's remarks, there may also be scope for PUBLIC_INCLUDES and
PRIVATE_INCLUDES keywords.
I think the normal include directories should be treated as PRIVATE, while
the PUBLIC ones should have to be set explicitely.
Assuming a library would have those PUBLIC_INCLUDES set, should they be used
automatically when linking against this library using target_link_libraries(),
so that the following two lines add the PUBLIC_INCLUDES from the myLib library
to the compilation of foo ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
I'd say no, because it would be invisible in this code that the
target_link_libraries() call adds an include-directory to the compilation.
This will make for harder debugging/understanding CMakeLists.txt you didn't
write yourself.
The target_include_directories() command from the other email could help with
this:
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
target_include_directories(foo /some/include/dir myLib)
or maybe an extra keyword for target_link_libraries(), something like ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib USE_INCLUDE_DIRECTORIES)
Just some ideas...
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] target_include_directories branch in stage
On 11/6/2011 5:45 PM, Stephen Kelly wrote:
As discussed on the cmake user mailing list, I'm interesting in implementing
the feature of target specific and configuration specific include
directories.
Thanks for working on this.
I've pushed the target-include-directories branch to stage, which implements
the feature. I started out as prototyping, but I ended up implementing API
that I think makes sense. I have not merged it into next yet as it is not
certain if it should be in the next release. I'd prefer it to be though if
we can sort out the issues with what should be the target feature set.
Good. We can work on this and revise/rewrite the topic there first and then
merge to next for testing when the design is more mature.
David mentioned one issue is whether the include directories of a target
property should overwrite those of the directory property (added with the
command include_directories). Like others on the other thread, I would
expect the final list of includes to be determined by addition. For example:
One problem with determining by addition is the ordering, and a good deal
of your message talks about that. It is not just dir-vs.-target ordering.
Where do the per-config lists appear? Let's ignore per-config rules for
the moment and focus on dir-vs.-target, and return to per-config further down.
Unlike link rules we don't have any explicit dependencies or ordering
constraints among include directories. Ideally all include directories
would contain a disjoint set of files so that the order wouldn't matter,
but that isn't going to happen in general. Unless we can ask users to
specify ordering constraints we cannot do any automatic ordering. We
have no good way to merge/combine multiple include directory lists.
The solution has to be based on only a *single* include directory list.
We already do this for link libraries. The non-target link_directories
and link_libraries commands just append to lists kept for each directory.
When a target is created it's per-target link information is initialized
by copying the current directory-level version. After that only the
target_link_libraries command can add more rules for a target.
The INCLUDE_DIRECTORIES property of a target must be the *only* list
from which the final include directory list is constructed. When a target
is created the current directory-level include directories must be used
to initialize the list. Further include_directories() calls in the same
directory must append not only to the directory-level list but also to
the property for all existing targets. At any intermediate point a
target's property can be modified independently (see the set_property
command example below).
Now we can return to per-config include directories. To incorporate them
into the same single list, we will need some kind of markup on a per-entry
basis. This is similar to the debug/optimized keywords used by the
target_link_libraries command, but must be more well designed. Perhaps
a syntax similar to generator expressions in custom commands can work.
I'll have to think more about it.
target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h)
I'd like to get this working using only the raw target property first:
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES ${foo_INCLUDES})
and discuss a new command separately later.
* I have only tried to implement this with the makefile generator and have
so far only tested it with Unix Makefiles. One of the bugs says XCode
can't do source-level includes. Can it do target-level includes?
I haven't checked recently but I think it can do both. The concern may be
per-source flags that vary by configuration.
Would I have to implement this for all generators before it would be
considered for acceptance?
Yes, at least someone would have to implement it for each generator.
So before I merge this into next, I'm wondering if this feature can be
considered for inclusion in 2.8.7?
Whatever features are mature and merged to master before the release will
be in it. We won't hold up a release for this though.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On 11/6/2011 5:49 PM, Stephen Kelly wrote: Stephen Kelly wrote: Issues: * I have only tried to implement this with the makefile generator and have so far only tested it with Unix Makefiles. One of the bugs says XCode can't do source-level includes. Can it do target-level includes? Would I have to implement this for all generators before it would be considered for acceptance? * There's scope for refactoring the new code in my branch as well as potentially refactoring with the cmIncludeDirectoriesCommand. * There's scope for optimization. * I haven't written any tests yet. Related to Alex's remarks, there may also be scope for PUBLIC_INCLUDES and PRIVATE_INCLUDES keywords. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39200 This is a separate problem. It is about propagating include directories through usage requirements of a library, just like the link interface. Let's start with per-target/config include directories. -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] target_include_directories branch in stage
On Monday 07 November 2011, Alexander Neundorf wrote: On Sunday 06 November 2011, Stephen Kelly wrote: Hi, As discussed on the cmake user mailing list, I'm interesting in implementing the feature of target specific and configuration specific include directories. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/foc us =39114 I've pushed the target-include-directories branch to stage, which implements the feature. I started out as prototyping, but I ended up implementing API that I think makes sense. I have not merged it into next yet as it is not certain if it should be in the next release. I'd prefer it to be though if we can sort out the issues with what should be the target feature set. David mentioned one issue is whether the include directories of a target property should overwrite those of the directory property (added with the command include_directories). Like others on the other thread, I would expect the final list of includes to be determined by addition. I replied over there to this question. Here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114 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] target_include_directories branch in stage
On 11/7/2011 12:57 PM, Brad King wrote:
The INCLUDE_DIRECTORIES property of a target must be the *only* list
from which the final include directory list is constructed. When a target
is created the current directory-level include directories must be used
to initialize the list. Further include_directories() calls in the same
directory must append not only to the directory-level list but also to
the property for all existing targets. At any intermediate point a
target's property can be modified independently (see the set_property
command example below).
Alex suggested the same thing:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39227
On 11/7/2011 12:23 PM, Alexander Neundorf wrote:
I think
get_target_properties(someVar foo INCLUDE_DIRECTORIES)
should return the full list of include directories used for that target.
This would mean that they are not really additive.
Instead, the INCLUDE_DIRECTORIES target property could be initialized from the
directory-property INCLUDE_DIRECTORIES.
Then, to add include dirs, use
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES ${bar_INCLUDES} )
To set (and ignore any directory-level include dirs):
set_property(TARGET foo PROPERTY INCLUDE_DIRECTORIES ${blub_INCLUDES} )
-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
