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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
