[cmake-developers] push of LinkOptionsCommand topic branch

[Steve Wilson]

On Feb 5, 2014, at 10:51 AM, Stephen Kelly <steveire at gmail.com> wrote:

>>> 4) Tests should avoid bad practices like using target_link_options to add
>>> libraries. Instead try to choose suitable link flags for the tests.
>> 
>> I’m having a little trouble with your notion of ‘bad practices.’   I’m
>> sure you have good reasons for making the determination that they are bad
>> practices, but to me they seem somewhat arbitrary.
> 
> Generally, cmake managed the libraries that are linked to (specified via 
> target_link_libraries) so that it can determine the proper link line, and 
> set up dependencies in the buildsystem so that a change in the library 
> causes a rebuild. Specifying a library in target_link_options would bypass 
> that. I don't know of a reason that 
> 
> target_link_options(tgt PRIVATE -llibsomething)
> 
> is better than
> 
> target_link_libraries(tgt PRIVATE -llibsomething)
> 
> and should be encouraged. If there is a reason, maybe I just don't know 
> about it.
> 
>> Is there some design document that you are using to make these
>> determinations?
> 
> No, just awareness of the cmake feature and existing commands etc for 
> handling libraries, and some awareness of the reason to use the particular 
> commands. I would say that using target_link_options() to link to libraries 
> should be discouraged in the documentation of that command unless there's a 
> particular reason to recommend it in some case?
> 
>> I realize that CMake has different mechanisms for explicitly
>> handling libraries, but the point isn’t to handle the library, the point
>> was just to pass a reasonable linker option.
> 
> Ok, I'm not aware of a reason to do that, but if there is a good one, it 
> might be worth adding it to the documentation.

I think the question here then is whether or not unit tests should be considered documentation of a command/feature.   The unit test I wrote was written from the perspective that I wanted to test a linker option.   -llibrary is a valid linker option.   This has nothing to do with target_link_libraries() etc…  It is simply just testing a linker option.   Now, everything you have said about not encouraging this kind of usage for target_link_options() and libraries, etc… is valid.   However, does that standard apply to tests.   Are tests just tests? Or should they also be considered at the same level of documentation?   If they should be considered documentation in the sense that they should be examples applied CMake methodology in all cases, perhaps that should be communicated better.   By better, I mean up front, not after the fact.

On a complete side note,I have to say that the tests make pretty difficult to read documentation.   In the grand scheme of documentation they seem quite obfuscated.   Of courses tests would appear that way because you often have to use interesting twists to accomplish a test of a feature.

I’m not trying to argue that tests should become a sloppy application of various principles of CMake usage, I’m just pointing out that in testing a linker option, it was a valid test, even though in actual usage you would link libraries with target_link_libraries().    Are there better tests?   Sure.   That still doesn’t mean the one test is an invalid test.



>>> On GNU, you can do this:
>>> 
>>> add_executable(foo foo.cpp)
>>> target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main)
> 
>> Does that make sense?  How should I determine what is bad practice in the
>> face of what is reasonable?
> 
> I would say that tests and documentation should assume the use of the CMake 
> features for managing the linked libraries. 
> 
> Additionally, I find the test with the --ignore-unresolved-symbol option 
> preferable because it does not rely on the existence of outside files.

Yes, that is a very valid point.  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140205/64c18c96/attachment-0002.sig>