[cmake-developers] push of LinkOptionsCommand topic branch

[Steve Wilson]

On Feb 5, 2014, at 3:06 PM, Stephen Kelly <steveire at gmail.com> wrote:

> Steve Wilson wrote:
> 
>> 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?
> 
> Admittedly, the target_compile_options tests use defines as test input. I'd 
> gladly swap that out for an alternative flag if there were a suitable flag 
> which gave us the same test coverage on the dashboard. The 
> add_compile_options command documents itself as not suitable for 
> preprocessor defines and include directories, however. I guess 
> target_compile_options documentation should get a similar note.
> 
> I would also like to see the target_link_options documentation discourage 
> use for specifying libraries.
> 
> If you feel so strongly about using a -llibrary flag in the tests, then 
> that's ok, but for me 'the file must exist' is a winning argument in favor 
> of not doing that.

I agree, ‘the file must exist’ is a winning argument.   

I’m not trying to push for this type of test of using libraries with target_link_options or add_link_options. (I’m already working on changes on the order that you suggested).   My question has evolved more into the question of ‘what are first principles for tests?' 

-------------- 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/a2746880/attachment-0002.sig>