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
