Re: [cmake-developers] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Wednesday 31 July 2013, Brad King wrote: On 07/31/2013 06:44 AM, Stephen Kelly wrote: Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. I agree. Several of Steve's topics are more mature than the one proposed here and he's waiting until after 2.8.12 for them. I retract my proposal and deleted the branch from stage. Since it was decided by KDE that the next generation of KDE libraries will make use of imported target names directly I think it doesn't make sense to add another standard variable nobody uses. IMO this also means that also in the future there will be no standard for the naming of the results of a find_package() call. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Tuesday 20 August 2013, Stephen Kelly wrote: Alexander Neundorf wrote: I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets I still don't know what for. Can it do anything I can't do by simply setting a variable to the aliased target(s) ? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7370/focu s=7394 Ah, that one. I didn't understand that back then. Does that mean that the export() call now happens later, so that in the following line the file does not yet exist, so the imported targets cannot be loaded ? How does the alias target help with that ? and double-colons-means-IMPORTED. I haven't followed closely. Does this mean creating a normal target which contains :: will be a cmake error ? Something like that, yes, with a policy. And I guess creating an imported target without :: will still be ok ? 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Wednesday 31 July 2013, Stephen Kelly wrote: Alexander Neundorf wrote: Comments ? If possible, I'd like to get that into 2.8.12. Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I'm (still) kind of willing to put in the work in kdelibs to get a proper buildsystem and work on that. You disagree about the way to do that. Everybody else is not working on it, and will more or less just accept the proposed solution. I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets I still don't know what for. Can it do anything I can't do by simply setting a variable to the aliased target(s) ? and double-colons-means-IMPORTED. I haven't followed closely. Does this mean creating a normal target which contains :: will be a cmake error ? My preference is for 2.8.12 to be out soon and get those features into I'd like to have that in 2.8.12 so we can make use of it in kde frameworks in a few weeks, not in 5 months or so. I.e. come to a somewhat clean buildsystem. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets I still don't know what for. Can it do anything I can't do by simply setting a variable to the aliased target(s) ? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7370/focus=7394 and double-colons-means-IMPORTED. I haven't followed closely. Does this mean creating a normal target which contains :: will be a cmake error ? Something like that, yes, with a policy. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote:
On Monday 29 July 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
So it can be used in tll() calls to link against the library (package).
What makes it differ from Foo_LIBRARIES, is that CMake checks that each
of the items listed in this variable
* is an existing target
* has the INTERFACE_INCLUDE_DIRS property set.
Are you really certain it is always an error for a target to not set
this?
I think so.
If I want to use symbols from a library, I should include its headers, and
for that the include dirs need to be known.
For header-only libraries even more.
Are there cases where this is not the case ?
There will/can be in the future.
add_library(picon INTERFACE)
set_property(TARGET picon INTERFACE_POSITION_INDEPENDENT_CODE ON)
add_library(picoff INTERFACE)
set_property(TARGET picoff INTERFACE_POSITION_INDEPENDENT_CODE ON)
...
# Use linking to psuedo targets to enable compiler options:
add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE picon)
add_executable(bar main.cpp)
target_link_libraries(bar PRIVATE picoff)
Or:
add_library(cxx11features INTERFACE)
set_property(TARGET cxx11features
INTERFACE_COMPILE_OPTIONS
$$CXX_COMPILER_ID:GNU:-std=c++0x
$$CXX_COMPILER_ID:Clang:-std=c++11
)
set(IS_GNU $CXX_COMPILER_ID:GNU)
set(IS_46 $VERSION_GREATER:$CXX_COMPILER_VERSION,4.6)
set_property(TARGET cxx11features
INTERFACE_COMPILE_DEFINITIONS
$$AND:${IS_GNU},${IS_46}:CXXFEATURES_NULLPTR_FOUND
)
# Possibly also specify libcxx compiler option if using
# recent clang on apple.
...
add_executable(foo main.cpp)
target_link_libraries(foo cxx11features)
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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: Comments ? If possible, I'd like to get that into 2.8.12. Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. When do you want to create 2.8.12 RC1? 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/31/2013 06:44 AM, Stephen Kelly wrote: Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. I agree. Several of Steve's topics are more mature than the one proposed here and he's waiting until after 2.8.12 for them. When do you want to create 2.8.12 RC1? As soon as things are polished up on the dashboard and we have time to initiate the RC cycle. Hopefully early next week. -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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/26/2013 04:17 PM, Alexander Neundorf wrote: This should make sure that using this variable in a tll() call should suffice to give the target the required include dirs and libraries. Sounds good! I propose the name Foo_LIBRARY_TARGETS instead because the intended use case is only for libraries. KCoreAddons_TARGETS set by it lists the following non-existant targets: Foo s/existant/existent/ * Should the variable be mentioned in the documentation for find_package() ? Yes, since it is this command that enforces the error messages. * There is the theoretical risk that there are Config.cmake files out there which set a variable with that name already, but without the include dir property. Should this be based on a policy, so that the error is only generated if cmake 2.8.12 or higher is required ? I think with the name pkg_LIBRARY_TARGETS the risk is small. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: So it can be used in tll() calls to link against the library (package). What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the items listed in this variable * is an existing target * has the INTERFACE_INCLUDE_DIRS property set. Are you really certain it is always an error for a target to not set this? Comments ? If possible, I'd like to get that into 2.8.12. I'm still planning on getting the 'double colons for IMPORTED targets' feature in, but after 2.8.12. This is orthogonal, but the motivation is similar. My preference is to get a 2.8.12 out soon and open up for features after that. I have a few waiting for that already. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Stephen Kelly wrote: Alexander Neundorf wrote: So it can be used in tll() calls to link against the library (package). What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the items listed in this variable * is an existing target * has the INTERFACE_INCLUDE_DIRS property set. Are you really certain it is always an error for a target to not set this? I think so. If I want to use symbols from a library, I should include its headers, and for that the include dirs need to be known. For header-only libraries even more. Are there cases where this is not the case ? Don't know about Fortran. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Brad King wrote: On 07/26/2013 04:17 PM, Alexander Neundorf wrote: This should make sure that using this variable in a tll() call should suffice to give the target the required include dirs and libraries. Sounds good! I propose the name Foo_LIBRARY_TARGETS instead because the intended use case is only for libraries. I already thought the same, that this thing is not for all imported targets, i.e. plugins, executables and libraries, but only for libraries. It's juts a bit long. Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? KCoreAddons_TARGETS set by it lists the following non-existant targets: Foo s/existant/existent/ * Should the variable be mentioned in the documentation for find_package() ? Yes, since it is this command that enforces the error messages. I pushed that to the branch on stage. I guess you'll want to have a look at it, it can probably be improved. :-) 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/29/2013 04:10 PM, Alexander Neundorf wrote: On Monday 29 July 2013, Stephen Kelly wrote: Are you really certain it is always an error for a target to not set this? I think so. If I want to use symbols from a library, I should include its headers, and for that the include dirs need to be known. For header-only libraries even more. Are there cases where this is not the case ? Don't know about Fortran. Not all targets provided in a package need to be listed by the package config file in the pkg_LIBRARY_TARGETS variable. The restriction here is that those that are listed in the variable need to have INTERFACE_INCLUDE_DIRS set, even if empty. -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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/29/2013 04:41 PM, Alexander Neundorf wrote: Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? I'd prefer the more precise name. I guess you'll want to have a look at it, it can probably be improved. :-) I'll take a look when I get a chance. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Brad King wrote: On 07/29/2013 04:41 PM, Alexander Neundorf wrote: Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? I'd prefer the more precise name. I guess you'll want to have a look at it, it can probably be improved. :-) I'll take a look when I get a chance. Thanks. This is now in the IntroduceLIBRARY_TARGETSVariable branch. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
... TODO * Tests are still missing. It has tests in the meantime. 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
