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
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
