Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly wrote: If you build a library using foo.cpp it will contain the glVertex2i symbol even though its headers wont include it. Likewise a consumer of that library does not need to have the headers, but will need to link against a library containing the symbol. Ah, I guess we're talking about static libraries here. Given this, you might consider wrapping the dependencies in $LINK_ONLY in the INTERFACE. That would match the behavior of cmExportFileGenerator I think. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly steve...@gmail.com writes: Philipp Möller wrote: To simplify exporting targets I added IMPORTED targets to some of the Find modules. Thanks for working on this. Just a few minor comments: In the FindX11 documentation commit, one of the changes is to replace use of two spaces between sentences with one. That's counter to the prevailing style in CMake. cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and Qt 5 emulates that. It could be done with these files too (I notice in FindGLUT at least). I don't know if it has any effect on IMPORTED targets, but it may in the future even if it does not currently. That sounds like a good idea. Although I think that would make things very confusing: the IMPORTED_LOCATION would be the full path of the library, the INTERFACE_INCLUDE_DIRECTORIES would be the full path to the includes, but all of this is ignored as soon as -framework is used and the full path to the framework isn't specified (as far as my understanding of OSX goes). Maybe it would make sense to add a FRAMEWORK library type and a find_framework command to encapsulate all this. It would make writing those imports a lot smoother as well. Is there any reason to make the boost components not depend on each other? Or is that just left for future development? The Boost module documents that component imported targets have lower-case names, but that is not the case (haha). The names depend on the arguments to find_package currently: find_package(Boost REQUIRED Thread) if (TARGET Boost::Thread) message(YES) else() message(NO) endif() AFAIK, the documentation says that components should be specified by their canonical name. Unfortunately, it doesn't say what that is exactly and I blindly assumed it to always be lower-case. I'll fix this. It looks like a good idea to add Boost::boost to the INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported target. I contemplated that, but here I tried to anticipate Boost modularization. If we ever get specific include directories for each component we can break a lot of builds that wrongly relied on the fact that we brought in all of the Boost includes. If the includes are separated, this will be much easier to adapt to for users. I would say something similar about the GLUT imported targets, but it seems that only GLUT::GLUT is documented, so presumably it is the only one intended for users to use. Is it verified that the other libraries are really interface dependencies and not runtime requirements? If they are really interface usage requirements, where are the headers of the other libraries located? I don't understand what you mean by 'runtime requirements'. GLUT depends on either some X11 libraries or Cocoa for window creation, but doesn't expose the system APIs directly. You will still need to link against them. I just went through the freeglut implementation and the external headers are only windows.h, gl.h, and glu.h. Those dependencies also missing in the original FindGLUT and this would be a worthwhile fix. Multiple IMPORTED_LOCATION_CONFIG are populated on the boost targets, but the IMPORTED_CONFIGURATIONS target property is not populated. Thanks. Didn't know this was necessary. Will be fixed. Is there a need to populate the IMPORTED_IMPLIB_CONFIG target properties on Windows for any of the targets? I don't have a Windows machine available right now, but I can try to figure this out later. Windows users tend to rely on Boost auto-linking though, which unfortunately doesn't interact very well with IMPORTED targets. cmExportFileGenerator populates the IMPORTED_LINK_INTERFACE_LANGUAGES target property, and Qt 5 emulates that. The same could be set to CXX at least for the Boost targets. Will be fixed. One of the reasons Qt imported targets are called Qt4::Foo and Qt5::Foo is to avoid accidental combination of, say, Qt::Core and Qt::Gui from different major versions. They also encode a INTERFACE_QT_MAJOR_VERSION and add QT_MAJOR_VERSION to the COMPATIBLE_INTERFACE_STRING target property. Something similar could be added for these imported targets. In the case of Boost, because they don't provide binary compatibility or promise source compatibility, it might make sense to encode the full version, not only the major version, in a similar way to ensure that only boost libraries from the same boost release are used together. In the future, post modularization, boost may attempt to release some modules on a separate release schedule and with disparate version numbers. They may still release 'boost foobar 1.3' with 'Boost 1.58' though, so '1.58' would still be the appropriate 'distribution version' to encode. [...snipped...] In the case of boost, it would also make sense to add INTERFACE_MULTITHREADED to the targets and
Re: [cmake-developers] IMPORTED targets for some Find modules
Philipp Moeller wrote: Stephen Kelly steve...@gmail.com writes: cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and Qt 5 emulates that. It could be done with these files too (I notice in FindGLUT at least). I don't know if it has any effect on IMPORTED targets, but it may in the future even if it does not currently. That sounds like a good idea. Although I think that would make things very confusing: the IMPORTED_LOCATION would be the full path of the library, the INTERFACE_INCLUDE_DIRECTORIES would be the full path to the includes, but all of this is ignored as soon as -framework is used and the full path to the framework isn't specified (as far as my understanding of OSX goes). I don't have great understanding of OSX either I'm afraid. It looks like a good idea to add Boost::boost to the INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported target. I contemplated that, but here I tried to anticipate Boost modularization. If we ever get specific include directories for each component we can break a lot of builds that wrongly relied on the fact that we brought in all of the Boost includes. If the includes are separated, this will be much easier to adapt to for users. If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED target, what can go wrong? I would say something similar about the GLUT imported targets, but it seems that only GLUT::GLUT is documented, so presumably it is the only one intended for users to use. Is it verified that the other libraries are really interface dependencies and not runtime requirements? If they are really interface usage requirements, where are the headers of the other libraries located? I don't understand what you mean by 'runtime requirements'. GLUT depends on either some X11 libraries or Cocoa for window creation, but doesn't expose the system APIs directly. You will still need to link against them. You mean they must appear on the link line of your program? If so, then they are public dependencies of GLUT. Or they have to be available only at runtime? If so then they are private dependencies of GLUT. If they must appear on the link line of your program, then your program must use symbols from it, and then you need to have a definition of those symbols at compile time, which is usually provided in header files. Typically that happens if the headers of one library (Cocoa, in this case I think) are #included in the headers of another library (GLUT, in this case I think). Is that the case? If not, then Cocoa is a private dependency. I just went through the freeglut implementation and the external headers are only windows.h, gl.h, and glu.h. Those dependencies also missing in the original FindGLUT and this would be a worthwhile fix. Then Cocoa etc are 'private dependencies', not 'public dependencies' and do not need to appear in the INTERFACE_LINK_LIBRARIES target property. Is there a need to populate the IMPORTED_IMPLIB_CONFIG target properties on Windows for any of the targets? I don't have a Windows machine available right now, but I can try to figure this out later. Windows users tend to rely on Boost auto-linking though, which unfortunately doesn't interact very well with IMPORTED targets. I don't know what auto-linking is and why that would not interact well with IMPORTED targets. Others to consider for this compatibility requirement are the Boost_COMPILER, Boost_NAMESPACE, Boost_THREADAPI etc. Those changes would greatly enhance usability and I'll look into implementing them. For now I went with a minimal system that does not grant more safety than you would already get with the old-school variable style. The problem is that if you implement the IMPORTED targets without using these compatibility features, adding them in the future would be a breaking change. CMake code might happen to work before you add them and break afterward. Adding them now would introduce 'safe failure' early. First we need to get dependencies between Boost libraries figured out and then we should move on towards the full feature set. Note also that the dependencies may have changed over time (and over boost releases). You could add specify the dependencies for only the most recent release, but even that is optional and can be done in the future. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at
Re: [cmake-developers] IMPORTED targets for some Find modules
David Cole via cmake-developers wrote: I don't know what auto-linking is and why that would not interact well with IMPORTED targets. Auto-linking is header files telling the linker what libraries to link to (via pragma comment lib in the MS compilers): http://en.wikipedia.org/wiki/Auto-linking http://msdn.microsoft.com/en-us/library/7f0aews7.aspx I've always had to define the preprocessor symbol in boost (and I always have to look it up, because I can't remember what it is) to suppress auto-linking in order to get boost to work with a CMake-based build of something that depends on boost. Using auto-linking successfully usually involves specifying link directories, and libraries by file name only (not full path), ... perhaps that is one reason why it doesn't interact easily with CMake in general. Thanks. That indeed doesn't seem to interact well with CMake. The introduction of imported targets is an opportunity to add the necessary define to disable it to INTERFACE_COMPILE_DEFINITIONS by default, if that is desired. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
On 06/25/2014 02:53 PM, Stephen Kelly wrote: David Cole via cmake-developers wrote: Thanks. That indeed doesn't seem to interact well with CMake. The introduction of imported targets is an opportunity to add the necessary define to disable it to INTERFACE_COMPILE_DEFINITIONS by default, if that is desired. I would like that very much as well. I've got a custom FindBoost.cmake which basically just wraps the actual FindBoost module and sets the BOOST_ALL_NO_LIB definition. This seems to be a source of confusion for people who are unaware of autolinking in general. Having CMake find and link one set of libraries (DLL by default) and the lib pragmas link yet another set of libraries (static by default). Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Nils Gladitz nilsglad...@gmail.com
writes:
On 06/25/2014 02:53 PM, Stephen Kelly wrote:
David Cole via cmake-developers wrote:
Thanks. That indeed doesn't seem to interact well with CMake.
The introduction of imported targets is an opportunity to add the necessary
define to disable it to INTERFACE_COMPILE_DEFINITIONS by default, if that is
desired.
I would like that very much as well.
I'll look into doing that. I think populating
INTERFACE_COMPILE_DEFINTIONS with BOOST_${LIBRARY_NAME}_NO_LIB seems the
obvious choice. In addition I can provide a Boost::disable_autolinking
target to disable it for the complete library.
I've got a custom FindBoost.cmake which basically just wraps the
actual FindBoost module and sets the BOOST_ALL_NO_LIB definition.
Another option is to wrap FindBoost and simply unset ${Boost_LIBRARIES}
on Windows after it completed and to make sure the link directories are
set.
This seems to be a source of confusion for people who are unaware of
autolinking in general.
Having CMake find and link one set of libraries (DLL by default) and
the lib pragmas link yet another set of libraries (static by default).
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Philipp Moeller wrote:
Nils Gladitz nilsglad...@gmail.com
writes:
I would like that very much as well.
I'll look into doing that. I think populating
INTERFACE_COMPILE_DEFINTIONS with BOOST_${LIBRARY_NAME}_NO_LIB seems the
obvious choice.
Yes.
In addition I can provide a Boost::disable_autolinking
target to disable it for the complete library.
Also consider a CMake variable to disable the addition of the defines (by
not linking the interface targets).
set(Boost_ENABLE_AUTOLINKING 1)
find_package(Boost)
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly steve...@gmail.com writes:
Philipp Moeller wrote:
[...snipped...]
I contemplated that, but here I tried to anticipate Boost
modularization. If we ever get specific include directories for each
component we can break a lot of builds that wrongly relied on the fact
that we brought in all of the Boost includes. If the includes are
separated, this will be much easier to adapt to for users.
If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED
target, what can go wrong?
On a non-modularized build I will need to populate it with
Boost_INCLUDE_DIR as we don't do detection of different include
directories yet. This would allow users to accidentally use headers from
a different component. The way it is done now, users will be aware that
they bring in all includes and know what to change if they wish to use a
modular Boost.
I would say something similar about the GLUT imported targets, but it
seems that only GLUT::GLUT is documented, so presumably it is the only
one intended for users to use. Is it verified that the other libraries
are really interface dependencies and not runtime requirements? If they
are really interface usage requirements, where are the headers of the
other libraries located?
I don't understand what you mean by 'runtime requirements'. GLUT
depends on either some X11 libraries or Cocoa for window creation, but
doesn't expose the system APIs directly. You will still need to link
against them.
You mean they must appear on the link line of your program? If so, then they
are public dependencies of GLUT.
Or they have to be available only at runtime? If so then they are private
dependencies of GLUT.
If they must appear on the link line of your program, then your program must
use symbols from it, and then you need to have a definition of those symbols
at compile time, which is usually provided in header files.
Not necessarily. Imagine:
foo.h:
void f();
foo.cpp:
#include foo.h
#include GL/gl.h
void f() {
glVertex2i(1, 2);
}
If you build a library using foo.cpp it will contain the glVertex2i
symbol even though its headers wont include it. Likewise a consumer of
that library does not need to have the headers, but will need to link
against a library containing the symbol. This is exactly the case in
GLUT. Thus they need to be PUBLIC or INTERFACE dependencies.
Typically that happens if the headers of one library (Cocoa, in this case I
think) are #included in the headers of another library (GLUT, in this case I
think).
Is that the case? If not, then Cocoa is a private dependency.
I just went through the freeglut implementation and the external
headers are only windows.h, gl.h, and glu.h. Those dependencies also
missing in the original FindGLUT and this would be a worthwhile fix.
Then Cocoa etc are 'private dependencies', not 'public dependencies' and do
not need to appear in the INTERFACE_LINK_LIBRARIES target property.
[...snipped...]
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Philipp Moeller wrote: Stephen Kelly steve...@gmail.com writes: If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED target, what can go wrong? On a non-modularized build I will need to populate it with Boost_INCLUDE_DIR as we don't do detection of different include directories yet. This would allow users to accidentally use headers from a different component. Please correct me where I go wrong here: 1) All boost releases (including the next one) are monolithic 2) So there is only one Boost_INCLUDE_DIR 3) So, different components don't have different usage-include-directories Are you talking about a scenario where there are multiple different Boost installations found at different prefixes? Or what do you mean about 'accidentally using headers from a different component'? The way it is done now, users will be aware that they bring in all includes and know what to change if they wish to use a modular Boost. add_executable(foo main.cpp) target_link_libraries(foo Boost::thread) should 'just work' without having to add another target to provide the include dir. I don't understand what you're saying or arguing for here, but if Brad does I guess he'll merge it :). If you build a library using foo.cpp it will contain the glVertex2i symbol even though its headers wont include it. Likewise a consumer of that library does not need to have the headers, but will need to link against a library containing the symbol. Ah, I guess we're talking about static libraries here. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly steve...@gmail.com writes:
Philipp Moeller wrote:
Nils Gladitz nilsglad...@gmail.com
writes:
I would like that very much as well.
I'll look into doing that. I think populating
INTERFACE_COMPILE_DEFINTIONS with BOOST_${LIBRARY_NAME}_NO_LIB seems the
obvious choice.
Yes.
In addition I can provide a Boost::disable_autolinking
target to disable it for the complete library.
Also consider a CMake variable to disable the addition of the defines (by
not linking the interface targets).
set(Boost_ENABLE_AUTOLINKING 1)
find_package(Boost)
I really would like to do that, but for that to work we need a
LINK_DIRECTORIES property. I opened a feature request for this some time
ago.
Let me give a quick summary of how auto-linking works so we have a
common understanding of it:
A header uses pragma comment(lib, library_name.lib). This triggers the
compiler to look for library_name.lib in all specified and implicit link
directories.
I think this sums up what we need: If we enable auto-linking the
IMPORTED targets need to be INTERFACE targets that propagate a
INTERFACE_LINK_DIRECTORY property if the compiler supports
auto-linking. If it is disabled or the compiler does not support it, we
need a UNKNOWN or STATIC library target with an
INTERFACE_COMPILE_DEFINITIONS to disable auto-linking.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Philipp Moeller wrote:
Stephen Kelly steve...@gmail.com writes:
Also consider a CMake variable to disable the addition of the defines (by
not linking the interface targets).
set(Boost_ENABLE_AUTOLINKING 1)
find_package(Boost)
I really would like to do that, but for that to work we need a
LINK_DIRECTORIES property. I opened a feature request for this some time
ago.
Perhaps the name I used was confusing.
I am suggesting a way for the user to disable the automatic addition of the
BOOST_${LIBRARY_NAME}_NO_LIB defines.
If that define is always always wanted, (which appears to be the case), then
you can simply disregard my suggestion.
The 'obvious' name for such a variable would be
Boost_DISABLE_NO_AUTOLINKING
but I used a name which avoids double-negation.
Anyway, you know best whether it should be controllable by the user, so I
defer to you on that.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
On Wed, Jun 25, 2014 at 16:21:20 +0200, Stephen Kelly wrote: The 'obvious' name for such a variable would be Boost_DISABLE_NO_AUTOLINKING but I used a name which avoids double-negation. Could it just be called Boost_ENABLE_AUTOLINKING and avoid negations altogether? --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Ben Boeckel wrote: On Wed, Jun 25, 2014 at 16:21:20 +0200, Stephen Kelly wrote: The 'obvious' name for such a variable would be Boost_DISABLE_NO_AUTOLINKING but I used a name which avoids double-negation. Could it just be called Boost_ENABLE_AUTOLINKING and avoid negations altogether? That triggers a recursion :) http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10332/focus=10372 Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly steve...@gmail.com writes: Philipp Moeller wrote: Stephen Kelly steve...@gmail.com writes: If you populate the INTERFACE_INCLUDE_DIRECTORIES on each component IMPORTED target, what can go wrong? On a non-modularized build I will need to populate it with Boost_INCLUDE_DIR as we don't do detection of different include directories yet. This would allow users to accidentally use headers from a different component. Please correct me where I go wrong here: 1) All boost releases (including the next one) are monolithic 2) So there is only one Boost_INCLUDE_DIR 3) So, different components don't have different usage-include-directories Are you talking about a scenario where there are multiple different Boost installations found at different prefixes? Or what do you mean about 'accidentally using headers from a different component'? The way it is done now, users will be aware that they bring in all includes and know what to change if they wish to use a modular Boost. add_executable(foo main.cpp) target_link_libraries(foo Boost::thread) should 'just work' without having to add another target to provide the include dir. I don't understand what you're saying or arguing for here, but if Brad does I guess he'll merge it :). I was talking about a modularized Boost which doesn't use CMake. As long as stuff is monolithic this will bring in all include directories and the build will be harder to modularize. The way it is done now a user would need: add_executable(foo main.cpp) target_link_libraries(foo Boost::boost Boost::thread) and be aware that this just brought in all includes. If she ever switches to a modularized Boost this becomes: add_executable(foo main.cpp) target_link_libraries(foo Boost::thread) Maybe my thinking is too complex here and your example has merit. Some stuff should just work. If you build a library using foo.cpp it will contain the glVertex2i symbol even though its headers wont include it. Likewise a consumer of that library does not need to have the headers, but will need to link against a library containing the symbol. Ah, I guess we're talking about static libraries here. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
On 06/25/2014 06:52 AM, Philipp Moeller wrote: I'll open a new branch on GitHub as soon as the current changes hit master. Due to the discussion on FindBoost I decided to revert it from the topic in 'next' for now. Meanwhile I merged the rest of the changes from this thread to 'master'. That leaves just FindBoost, for which it sounds like more significant changes are being considered. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] IMPORTED targets for some Find modules
Philipp Möller wrote:
To simplify exporting targets I added IMPORTED targets to some of the
Find modules.
Thanks for working on this. Just a few minor comments:
In the FindX11 documentation commit, one of the changes is to replace use of
two spaces between sentences with one. That's counter to the prevailing
style in CMake.
cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and
Qt 5 emulates that. It could be done with these files too (I notice in
FindGLUT at least). I don't know if it has any effect on IMPORTED targets,
but it may in the future even if it does not currently.
Is there any reason to make the boost components not depend on each other?
Or is that just left for future development?
The Boost module documents that component imported targets have lower-case
names, but that is not the case (haha). The names depend on the arguments to
find_package currently:
find_package(Boost REQUIRED Thread)
if (TARGET Boost::Thread)
message(YES)
else()
message(NO)
endif()
It looks like a good idea to add Boost::boost to the
INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly
populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported
target.
I would say something similar about the GLUT imported targets, but it seems
that only GLUT::GLUT is documented, so presumably it is the only one
intended for users to use. Is it verified that the other libraries are
really interface dependencies and not runtime requirements? If they are
really interface usage requirements, where are the headers of the other
libraries located?
Multiple IMPORTED_LOCATION_CONFIG are populated on the boost targets, but
the IMPORTED_CONFIGURATIONS target property is not populated.
Is there a need to populate the IMPORTED_IMPLIB_CONFIG target properties
on Windows for any of the targets?
cmExportFileGenerator populates the IMPORTED_LINK_INTERFACE_LANGUAGES target
property, and Qt 5 emulates that. The same could be set to CXX at least for
the Boost targets.
One of the reasons Qt imported targets are called Qt4::Foo and Qt5::Foo is
to avoid accidental combination of, say, Qt::Core and Qt::Gui from different
major versions. They also encode a INTERFACE_QT_MAJOR_VERSION and add
QT_MAJOR_VERSION to the COMPATIBLE_INTERFACE_STRING target property.
Something similar could be added for these imported targets.
In the case of Boost, because they don't provide binary compatibility or
promise source compatibility, it might make sense to encode the full
version, not only the major version, in a similar way to ensure that only
boost libraries from the same boost release are used together. In the
future, post modularization, boost may attempt to release some modules on a
separate release schedule and with disparate version numbers. They may still
release 'boost foobar 1.3' with 'Boost 1.58' though, so '1.58' would still
be the appropriate 'distribution version' to encode.
[Aside: Some people want to release Qt modules with disparate version
schemes too, which has already caused problems:
http://thread.gmane.org/gmane.comp.lib.qt.devel/17144
One of the remaining unsolved problems is that Qt5 packages find their
dependencies with the same version as themselves, so
find_package(Qt5Gui)
which finds a version 5.3.1 Qt5Gui package will call
find_package(Qt5Core 5.3.1)
This obviously would either require mappings to be maintained ('what version
of Qt5 was Enginio 1.0.5/1.2.3 released with?'), or would need to be
dropped. That would be unfortunate because only combinations in the same
'distribution version' (which corresponds to the QtCore version) are tested
together.
But I digress...
]
In the case of boost, it would also make sense to add
INTERFACE_MULTITHREADED to the targets and COMPATIBLE_INTERFACE_BOOL. I'm
assuming that a multithreaded Boost::system can't be used with a non-
multithreaded Boost::filesystem for example. Currently I have the debian
package libboost-thread1.54-dev installed on my system but not the package
libboost-system1.54-dev, so FindBoost will find the thread component but not
the system component (in that prefix at least). Depending on the
build/package of boost it might be possible to conflict on things like that.
Others to consider for this compatibility requirement are the
Boost_COMPILER, Boost_NAMESPACE, Boost_THREADAPI etc.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to
