WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES

[Brandon J. Van Every]

wedekind wrote:
> Hello Brandon,
>
> thanks for your input.
>
>   
>> So you are the only person who ever builds your software?  If other people
>> have to build your stuff, you're making it a PITA for them, having to
>> remember precisely what Qt directory to use.  All this knowledge is locked
>>     
>
>   
>> up in your head, or in your docs, which nobody wants to read for such a
>> trivial issue.  If you ever pass the baton of maintenance on to someone
>> else, people are not going to thank you.
>>     
>
> :) I guess you already had the joy of taking over some maintenance scripts
> from anyone else?
>   

I spent 1 year migrating the Chicken Scheme build from GNU Autoconf to 
CMake.  I do not like things done in "odd" ways.  That said, the 
problems of Chicken were more about missing Windows support / 
consideration than about anything deliberately done in a lazy manner.  
What was there, was pretty well done.

>
> The point is: I need a trusted set of libs to link against, so flexibly
> looking for _any_ version/edition of a needed lib won't do.
>   

Ok that makes sense.  On Linux, people take all these huge stacks of 
open source libraries for granted.  On Windows, it's a nightmare, 
because the libs are not built regularly on Windows and tend to break.  
The best defenses of that are to (1) minimize external dependencies, (2) 
keep one's own version of the library in the source tree, either 
building it or using a canonical binary.

>
> Does that make sense to you? Can you think of a better solution?
>   

Well, even doing the above, there's the question of whether you feel 
these compatibility issues should get resolved.  That is, do you want 
more open source support burdens for yourself?  You could make the bug 
reports to Qt, the reproducers, the test scripts, etc.  In the long run, 
it might solve your build compatibility problems.  In the short run, it 
is always a waste of your time.  I'm pretty guarded about what projects 
I'll do that for nowadays.  Really, only CMake.

Even with CMake, I got lazy / desperately busy and didn't actually check 
whether all the good bugfixes they gave me for 2.4.4 beta were actually 
working.  I just trusted that the Kitware guys had tested the stuff 
decently before committing it to CVS.  They did, so when 2.4.4 shipped, 
I implemented all the new feature stuff, bumped the required version to 
2.4.4, and didn't bother with backwards compatibility at all.  It's a 
PITA writing if..else..endif to support multiple versions, especially 
when you're just working around old bugs that got fixed.  I could have 
done that early, during the beta, if I wanted to "smoothly pave the way" 
for the future.  But as it turned out, I certainly didn't have the 
time.  Even when I finally did the fixes, I just sorta threw them over 
the fence and hoped they worked, with only minimal testing before I 
committed them.  Nobody complained though.

I think, in open source, when you're making $0 from it, eventually you 
cut corners.  Too expensive to offer industrial grade migrations, where 
nobody ever sees a hiccup.

Which suggests another method: can you draft other people into doing the 
build testing / bug reporting for the Qt mishaps, so that the Qt people 
are properly pestered and the FIND problems get resolved?  In that 
school of thought, you leave some bugs available so that people will do 
something about them.  This requires an audience with a vested interest 
in having your stuff work, though.  No good if it's a personal project 
that no one else uses.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20061129/2b05c6b8/attachment.html