[CMake] link_libraries vs target_link_libraries
Fernando Cacciola
fernando.cacciola at gmail.com
Wed Nov 12 09:17:17 EST 2008
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
More information about the CMake
mailing list