Re: [CMake] link_libraries vs target_link_libraries
Colin D Bennett schrieb: However, I would argue that target_link_libraries vs. link_libraries is more important than the possible target_include_directories vs. include_directories, since the linked libraries will directly affect the generated output (linking to unnecessary libraries is wasteful). In contrast, including unused include-file-directories in the search path for the compiler will not affect the output (assuming there are no duplicated header file names in different paths, which I would argue should not be allowed). Actually, it's possible that those duplicated names exist. The problem comes up if they have the same API but a different ABI, thus the linking will possibly fail. However, doesn't include_directories() only affect the current dir and the subdirs? It would be a very rare case to have two apps in the same dir that use two different types/versions of the same include files. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
So, I guess I will comment on this... :) Originally CMake was directory based. We are moving towards being target based. For directories, targets, and projects, there should be a way to set: - defines - includes - link libraries - compiler flags Currently you can set: compiler flags: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS define symbols: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL libraries with target_link_libraries. config based compile defines: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG include_directories can only be set on a per directory basis. At some point a target will have all the links, includes, and flags required to use it stored somewhere, and that will come with the target. This can be done now with macros and functions, the new CMake build for boost does some of this. If someone wants to a bug entry could be created for target specific include files, that would be good. As for the title of the thread target_link_libraries should be used in most cases. However link_libraries could still be a useful short cut. Note, CMake does use the link libraries for a target transitively. If you do not want that, you can use: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill, Fernando Cacciola wrote: Ha I see... that is 2.6 specific right? There are still too many 2.4 versions shiped with Linux et al, and we don't want to ask our users to *manually* upgrade cmake when they already have one installed, so I'm keeping all compatible with at least 2.4.5 Well, not much we can do about that but wait... :) \ Indeed :) We are telling our users to do: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) target_link_libraries ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} ) But then I wondered: why am I bothering them with that last line while everything else is hidden in UseCGAL? After all if they do not won't to link with that, which would be really odd, they better don't use UseCGAL at all and rather just use the outcome of FindCGAL manually. So IMO UseCGAL should be all or nothing. Wouldn't you agree? For an executable is it not as important since there is no transitive linking. However, link_libraries is a bit of a blunt instrument as it will link with all the executables and libraries after it is called into sub directories. So, I still think linking just specific libraries is better than not. Also, it will be one less thing you have to change when 2.6 comes out. What if the project had program1 and program2, and program2 used VTK and CGAL, but program1 only used CGAL? Then the link_libraries approach would link too much. The extra includes should not hurt because VTK and CGAL should not have conflicting headers. So, there is a still a benefit to specifically linking libraries. In our case this scenario is just not possible at all since UseCGAL overrides flags, so everything following UseCGAL must actually use CGAL in all its glory :) We tell our users to arrange CMakeLists.txt appropiately taking the global side effects of UseCGAL into account. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Bill Hoffman schrieb: OTOH, it could make sense to do the following: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) use_CGAL( program ) so it works now with 2.4, and eventually upgrade it to use target properties instead. That sounds like a good way to go, and is similar to what the boost folks are doing. But it is not backwards-compatible and will fail to link on the new version while it worked fine on the old version. Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put the macro into FindCGAL.cmake. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hendrik Sattler wrote: Bill Hoffman schrieb: OTOH, it could make sense to do the following: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) use_CGAL( program ) so it works now with 2.4, and eventually upgrade it to use target properties instead. That sounds like a good way to go, and is similar to what the boost folks are doing. But it is not backwards-compatible and will fail to link on the new version while it worked fine on the old version. Why?? Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put the macro into FindCGAL.cmake. Which is far from being a problem, or is it? Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Fernando Cacciola schrieb: Hendrik Sattler wrote: Bill Hoffman schrieb: OTOH, it could make sense to do the following: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) use_CGAL( program ) so it works now with 2.4, and eventually upgrade it to use target properties instead. That sounds like a good way to go, and is similar to what the boost folks are doing. But it is not backwards-compatible and will fail to link on the new version while it worked fine on the old version. Why?? Because if the ${FOO_USE_FILE} doesn't do what it always does (globally adding this stuff), you _have_ to insert the new macro call to make it compile again. OTOH, this macro call will fail on the old version because it doesn't exist. (Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake) HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Hendrik, But it is not backwards-compatible and will fail to link on the new version while it worked fine on the old version. Why?? Because if the ${FOO_USE_FILE} doesn't do what it always does (globally adding this stuff), you _have_ to insert the new macro call to make it compile again. OTOH, this macro call will fail on the old version because it doesn't exist. (Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake) So you where referring to some existing UseFOO then? UseCGAL doesn't really exist yet (we haven't released it), so at this point I can do the right thing :) Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Colin, On Tue, 11 Nov 2008 16:13:43 -0200 Fernando Cacciola [EMAIL PROTECTED] wrote: Hi Andreas, On 11 Nov 2008 18:12:33 +0100, Andreas Pakulat wrote: In fact I don't understand why include_directories and add_definitions are not deprecated as well Which is precisely my point!! :) target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Yet OTOH given that those do not exists, it is just plain silly to recommend not using link_libraries, because it gets less than half the story right. I agree. There should be a target_include_directories. This has bothered me as well. However, I would argue that target_link_libraries vs. link_libraries is more important than the possible target_include_directories vs. include_directories, since the linked libraries will directly affect the generated output (linking to unnecessary libraries is wasteful). Agreed, though definitions and, most important of all by far, compiler and linker flags are much more critical. And UseVTK, for example, changes compiler flags FOR EVERYTHING THAT FOLLOWS, even totally unrelated PARENT directories (because of the ways of the cache). So if target_link_libraries makes sense (and it sure does), imagine TARGET_CMAKE_CXX_FLAGS (or even better target_add_compiler|linker_flags) In contrast, including unused include-file-directories in the search path for the compiler will not affect the output (assuming there are no duplicated header file names in different paths, which I would argue should not be allowed). Except of course that you can't disallow it in all cases since completely different libraries cannot possibly prevent clashing with each other, and that would happen if you have find_package(X) then find_package(Y). But granted, if you have those two lines in the same cmake scripts you are likely to need both X and Y in the same target, so this is an unlikely scenario. So, I think that target_link_libraries is more important than target_include_directories, but we still should have a target_include_directories for the sake of consistency, clarity (specifically show what include directories are used by what files), and robustness. And as I said far much more important: target_add_definitions and a way to target compilers and linker flags, which is something Use files also define globally now. Another aspect of this is that perhaps 'target_include_directories' is not the right concept, but rather, since include files are needed by source code (not compiled targets), the following: source_include_directories(source-files ... INCLUDES include-dirs ...) I wonder if this would be useful in practice? I'm not sure it makes sense to draw a disctinction between stuff needed by source files and compiled targets. While in a makefile these all go as command line parameters to the compiler source by source, in a project files these are global properties of a target within the project, so IMO the conceptual entity the encapsulates all these is the target, not the source files. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Am Wednesday 12 November 2008 17:03:04 schrieb Fernando Cacciola: Hi Hendrik, But it is not backwards-compatible and will fail to link on the new version while it worked fine on the old version. Why?? Because if the ${FOO_USE_FILE} doesn't do what it always does (globally adding this stuff), you _have_ to insert the new macro call to make it compile again. OTOH, this macro call will fail on the old version because it doesn't exist. (Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake) So you where referring to some existing UseFOO then? UseCGAL doesn't really exist yet (we haven't released it), so at this point I can do the right thing :) Sure but if this stuff is to be consistent with the other modules doing the USE_FILE thing, then this is a problem. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Fernando Cacciola wrote: Ha I see... that is 2.6 specific right? There are still too many 2.4 versions shiped with Linux et al, and we don't want to ask our users to *manually* upgrade cmake when they already have one installed, so I'm keeping all compatible with at least 2.4.5 Well, not much we can do about that but wait... :) \ We are telling our users to do: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) target_link_libraries ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} ) But then I wondered: why am I bothering them with that last line while everything else is hidden in UseCGAL? After all if they do not won't to link with that, which would be really odd, they better don't use UseCGAL at all and rather just use the outcome of FindCGAL manually. So IMO UseCGAL should be all or nothing. Wouldn't you agree? For an executable is it not as important since there is no transitive linking. However, link_libraries is a bit of a blunt instrument as it will link with all the executables and libraries after it is called into sub directories. So, I still think linking just specific libraries is better than not. Also, it will be one less thing you have to change when 2.6 comes out. What if the project had program1 and program2, and program2 used VTK and CGAL, but program1 only used CGAL? Then the link_libraries approach would link too much. The extra includes should not hurt because VTK and CGAL should not have conflicting headers. So, there is a still a benefit to specifically linking libraries. OTOH, it could make sense to do the following: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) use_CGAL( program ) so it works now with 2.4, and eventually upgrade it to use target properties instead. That sounds like a good way to go, and is similar to what the boost folks are doing. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On Wednesday 12 November 2008, Fernando Cacciola wrote: Hi Bill, ... Ha I see... that is 2.6 specific right? There are still too many 2.4 versions shiped with Linux et al, and we don't want to ask our users to *manually* upgrade cmake when they already have one installed, so I'm keeping all compatible with at least 2.4.5 KDE 4.2 (will be released early next year) will require cmake 2.6.2 (KDE svn trunk does since this monday), so distributions will adapt :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill, So, I guess I will comment on this... :) :) Originally CMake was directory based. We are moving towards being target based. For directories, targets, and projects, there should be a way to set: - defines - includes - link libraries - compiler flags Hard to argue with that :) Currently you can set: compiler flags: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS define symbols: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL libraries with target_link_libraries. config based compile defines: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG Ha I see... that is 2.6 specific right? There are still too many 2.4 versions shiped with Linux et al, and we don't want to ask our users to *manually* upgrade cmake when they already have one installed, so I'm keeping all compatible with at least 2.4.5 include_directories can only be set on a per directory basis. At some point a target will have all the links, includes, and flags required to use it stored somewhere, and that will come with the target. This can be done now with macros and functions, the new CMake build for boost does some of this. If someone wants to a bug entry could be created for target specific include files, that would be good. As for the title of the thread target_link_libraries should be used in most cases. However link_libraries could still be a useful short cut. The *practical* problem I have with target_link_libraries and which originated this thread is the following: We are telling our users to do: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) target_link_libraries ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} ) But then I wondered: why am I bothering them with that last line while everything else is hidden in UseCGAL? After all if they do not won't to link with that, which would be really odd, they better don't use UseCGAL at all and rather just use the outcome of FindCGAL manually. So IMO UseCGAL should be all or nothing. Wouldn't you agree? OTOH, it could make sense to do the following: find_packge( CGAL REQUIRED components ) include( ${CGAL_USE_FILE} ) add_executable( program ... ) use_CGAL( program ) In this case, the use_CGAL macro would set includes, definitions, libraries etc, but for the specified target as much as possible (depending on the current cmake support). IIUC I can easily write the use_CGAL macro as: include_directories ( ${CGAL_3RD_PARTY_INCLUDE_DIRS} ${CGAL_INCLUDE_DIRS} ) add_definitions ( ${CGAL_3RD_PARTY_DEFINITIONS}${CGAL_DEFINITIONS} ) link_directories ( ${CGAL_3RD_PARTY_LIBRARIES_DIRS} ${CGAL_LIBRARIES_DIR} ) target_link_libraries ( ${TARGET} ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} ) so it works now with 2.4, and eventually upgrade it to use target properties instead. What do yo think? Note, CMake does use the link libraries for a target transitively. If you do not want that, you can use: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES Ha, interesting.. didn't know that. Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas, On 11.11.08 14:12:39, Fernando Cacciola wrote: Hi Andreas, On 10.11.08 12:01:13, Fernando Cacciola wrote: The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) ... UseCGAL.cmake, as all such files, call include_directories, add_definitions and overrides (under certain circumstances) the compiler/linker flags that were used to build the CGAL library. These are all settings that affect any target added after the inclusion of UseCGAL.cmake. However, following the recommended practice (according to the documentation of the deprecated link_libraries command), UseCGAL DOES NOT call link_libraries. Instead, it realies on the user calling target_link_libraries himself. Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? Or am I missing something? There are projects that have headers that are usable without linking against any library. There are also projects installing their headers into a common place, that have multiple libraries. In that latter case you'd have include_directories() point to the common place for the headers, but obviously you can't know which of the libraries needs to be linked in. Who is you in your sentence? The UseXYZ modules which depends on the parameters to find_package(XYZ) certainly knows it. No it doesn't. UseXXX is a global thing, so it can't know which of the targets in a project need which files. Right, but the again a typical UseXYZ would do: include_directories( ${XYZ_INCLUDE_DIR} ) add_definitions( ${XYZ_DEFINITIOS} ) set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) ) So it doesn't know which of your targets need the include dirs, the definitions and the flags.. and it doesn't care. Boost is a good example (albeit it doesn't use cmake to build itself). There are various libraries shipped with it, they all install their headers into includedir/boost/libraryname/ and the libs are of course directly in libdir. And its common practice to have only includedir/boost in the include-directories. And BOOST_LIBRARIES is defined as a list of all libraries indicated by the user as boost components. Right, but those are all I'm going to use in my project, which might or might not be different from those that I want on target A and B. Right. So, if there where a UseBoost.cmake file which would do include_directories( ${BOOST_INCLUDE_DIR} ) add_definitions( ${BOOST_DEFINITIONS} ) then wouldn't it make sense for it to do link_libraries( ${BOOST_LIBRARIES} ) as well? That would mean _all_ my targets link against those libraries, which is completely wrong. Right. In fact I don't understand why include_directories and add_definitions are not deprecated as well Which is precisely my point!! :) target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Yet OTOH given that those do not exists, it is just plain silly to recommend not using link_libraries, because it gets less than half the story right. And IMO is equally silly to follow the recomendation and end up doing what most Use files typically do: to set so much that affects all subsequent targets, even compiler and linker flags, BUT simply define a variable XYZ_LIBRARY so a user can decide which target to link againt XYZ_LIBRARY. I mean, being able to control this is cool, sure, but why can I only control that and not the other equally critical settings??? IMO, if a user won't have real control over which targets actually use XYZ (in all the extent to which using XYZ, as defined by find_package(XYZ), means) then I rather don't bother them requiring users to call target_link_libraries by hand (while everything else is setup by the Use file itself). It's just silly. So to restat my point, if a UseFile does this: include_directories( ${XYZ_INCLUDE_DIR} ) add_definitions( ${XYZ_DEFINITIOS} ) set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) ) which shouldn't under the argument of what if I don't want that for all my targets, then it should do this as well: link_libraries( ${XYZ_LIBRARIES} ) Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Am Tuesday 11 November 2008 19:13:43 schrieb Fernando Cacciola: target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Did you notice set_property(TARGET .)? There, you can do add target specific definitions (even per build type) and other stuff. Sadly, this is no replacement for target_include_directories() as you have to know the compiler syntax. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On 11.11.08 14:12:39, Fernando Cacciola wrote: Hi Andreas, On 10.11.08 12:01:13, Fernando Cacciola wrote: The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) ... UseCGAL.cmake, as all such files, call include_directories, add_definitions and overrides (under certain circumstances) the compiler/linker flags that were used to build the CGAL library. These are all settings that affect any target added after the inclusion of UseCGAL.cmake. However, following the recommended practice (according to the documentation of the deprecated link_libraries command), UseCGAL DOES NOT call link_libraries. Instead, it realies on the user calling target_link_libraries himself. Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? Or am I missing something? There are projects that have headers that are usable without linking against any library. There are also projects installing their headers into a common place, that have multiple libraries. In that latter case you'd have include_directories() point to the common place for the headers, but obviously you can't know which of the libraries needs to be linked in. Who is you in your sentence? The UseXYZ modules which depends on the parameters to find_package(XYZ) certainly knows it. No it doesn't. UseXXX is a global thing, so it can't know which of the targets in a project need which files. Boost is a good example (albeit it doesn't use cmake to build itself). There are various libraries shipped with it, they all install their headers into includedir/boost/libraryname/ and the libs are of course directly in libdir. And its common practice to have only includedir/boost in the include-directories. And BOOST_LIBRARIES is defined as a list of all libraries indicated by the user as boost components. Right, but those are all I'm going to use in my project, which might or might not be different from those that I want on target A and B. So, if there where a UseBoost.cmake file which would do include_directories( ${BOOST_INCLUDE_DIR} ) add_definitions( ${BOOST_DEFINITIONS} ) then wouldn't it make sense for it to do link_libraries( ${BOOST_LIBRARIES} ) as well? That would mean _all_ my targets link against those libraries, which is completely wrong. In fact I don't understand why include_directories and add_definitions are not deprecated as well, those might not be wanted or can possibly even cause problems when building targets that don't depend on them. My point is that if a UseXYZ file defines taget-wide settings such as Its not target-wide, its project-wide - or at least directory wide. So even if you have all boost-linking targets of your project in one directory, you might not want all of them to link against all the boost libs you use. Maybe there are one or two libs that only need a subset of the boost-libs. Andreas -- You have a reputation for being thoroughly reliable and trustworthy. A pity that it's totally undeserved. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas, On 10.11.08 12:01:13, Fernando Cacciola wrote: The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) ... UseCGAL.cmake, as all such files, call include_directories, add_definitions and overrides (under certain circumstances) the compiler/linker flags that were used to build the CGAL library. These are all settings that affect any target added after the inclusion of UseCGAL.cmake. However, following the recommended practice (according to the documentation of the deprecated link_libraries command), UseCGAL DOES NOT call link_libraries. Instead, it realies on the user calling target_link_libraries himself. Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? Or am I missing something? There are projects that have headers that are usable without linking against any library. There are also projects installing their headers into a common place, that have multiple libraries. In that latter case you'd have include_directories() point to the common place for the headers, but obviously you can't know which of the libraries needs to be linked in. Who is you in your sentence? The UseXYZ modules which depends on the parameters to find_package(XYZ) certainly knows it. Boost is a good example (albeit it doesn't use cmake to build itself). There are various libraries shipped with it, they all install their headers into includedir/boost/libraryname/ and the libs are of course directly in libdir. And its common practice to have only includedir/boost in the include-directories. And BOOST_LIBRARIES is defined as a list of all libraries indicated by the user as boost components. So, if there where a UseBoost.cmake file which would do include_directories( ${BOOST_INCLUDE_DIR} ) add_definitions( ${BOOST_DEFINITIONS} ) then wouldn't it make sense for it to do link_libraries( ${BOOST_LIBRARIES} ) as well? My point is that if a UseXYZ file defines taget-wide settings such as includes, definitions etc.. then it should just as well define the link libraries... hence, link_libraries should not be deprecated and stock files like UseQt4 and UseVTK should us it (they don't FYI). Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries vs target_link_libraries
Hi people, The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) ... UseCGAL.cmake, as all such files, call include_directories, add_definitions and overrides (under certain circumstances) the compiler/linker flags that were used to build the CGAL library. These are all settings that affect any target added after the inclusion of UseCGAL.cmake. However, following the recommended practice (according to the documentation of the deprecated link_libraries command), UseCGAL DOES NOT call link_libraries. Instead, it realies on the user calling target_link_libraries himself. Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? Or am I missing something? TIA Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On 10.11.08 12:01:13, Fernando Cacciola wrote: The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) ... UseCGAL.cmake, as all such files, call include_directories, add_definitions and overrides (under certain circumstances) the compiler/linker flags that were used to build the CGAL library. These are all settings that affect any target added after the inclusion of UseCGAL.cmake. However, following the recommended practice (according to the documentation of the deprecated link_libraries command), UseCGAL DOES NOT call link_libraries. Instead, it realies on the user calling target_link_libraries himself. Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? Or am I missing something? There are projects that have headers that are usable without linking against any library. There are also projects installing their headers into a common place, that have multiple libraries. In that latter case you'd have include_directories() point to the common place for the headers, but obviously you can't know which of the libraries needs to be linked in. Boost is a good example (albeit it doesn't use cmake to build itself). There are various libraries shipped with it, they all install their headers into includedir/boost/libraryname/ and the libs are of course directly in libdir. And its common practice to have only includedir/boost in the include-directories. For the case of a single library with a few headers, for which a UseXXX file is provided the requirement really doesn't make much sense (IMHO) - unless you can use some of the headers without linking. Andreas -- Don't read any sky-writing for the next two weeks. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi, my 2c... 2008/11/10 Andreas Pakulat [EMAIL PROTECTED] On 10.11.08 12:01:13, Fernando Cacciola wrote: The CGAL library (www.cgal.org) uses cmake as build system. Thus, our users do: find_package(CGAL REQUIRED) include( ${CGAL_USE_FILE} ) There are projects that have headers that are usable without linking against any library. There are also projects installing their headers into a common place, that have multiple libraries. In that latter case you'd have include_directories() point to the common place for the headers, but obviously you can't know which of the libraries needs to be linked in. Boost is a good example (albeit it doesn't use cmake to build itself). they have just added cmake support, i think it was just added to the trunk There are various libraries shipped with it, they all install their headers into includedir/boost/libraryname/ and the libs are of course directly in libdir. And its common practice to have only includedir/boost in the include-directories. i would disagree, its common practice to have only includedir in the include-directories, and then you #include boost/shared_ptr.hpp For the case of a single library with a few headers, for which a UseXXX file is provided the requirement really doesn't make much sense (IMHO) - unless you can use some of the headers without linking. (snipped from above) On 10.11.08 12:01:13, Fernando Cacciola wrote: Well, I'm questioning this recommended practice because it's half baked: It makes sense to allow users to control which targets are linked against CGAL, but NOT if OTOH they cannot control which targets are given the CGAL include directories, definitions and flags. That is, IMO, target_link_libraries makes little sense in the absence of target_include_directories, target_add_definitions and target_*_FLAGS. What it's so special about linking that only that command can be made target specific??? I can specify which headers I want to include by writing #includes in my .cpp file. But the ONLY place I can specify which libraries I want to include is within CMake config files. Thus, you only need target_link_libraries and not target_add_directories. As for target_add_definitions, you don't add definitions to a target, you add them to cpp files you are compiling. I think you can define them for certain files if you have the add_definition in a subdirectory CMakeLists.txt, but I'm not sure how else you can limit its 'scope'. Paul ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake