On Monday 07 July 2008, you wrote: > Alexander Neundorf wrote: > >I just checked, a check for X11 is part of FindQt4.cmake since rev 1.1 > > in cmake cvs, almost exactly 3 years old. > >Do you think it's worth changing this ? > >(adds a difference to the version from cmake and might break some builds > > which accidentially use the X11 vars defined by this FIND_PACKAGE(X11) > > ) > > This would be akin to a source-incompatible change in CMake, I understand.
Yes, but only a small one (which could maybe be called a bug) (small incompatibility, hmmm, ... sounds like a "little bit pregnant"....). > But this isn't beyond the gcc developers, though: with gcc 4.3, they've > made their headers a lot more strict, meaning you cannot assume that > #including a file will bring another along. (For example, #include > <string> will not #include <string.h> anymore, so no memcpy will be > defined) Yes, gcc developers dare to break a lot of stuff (relatively). Actually I wonder why they get away with this. > But that requirement there makes using Qt require the X11 headers, which > isn't always so. You're fully allowed to do development with Qt without > X11 headers installed (provided you're not using static builds). You > can't build Qt without them -- but once you have, you can remove them. > > Of course, this means you can't pass -lX11 on the linking command-line > when linking to QtGui... and qmake itself isn't generating the proper > Makefiles yet. > > This again goes back to what I've been saying: all applications must > declare all of its direct dependencies. It uses X11? FIND_PACKAGE + > TARGET_LINK_LIBRARIES and whatever else. Yes. Well, I don't have a strong opinion on this. If you think it's somewhat important, I'd say we do this after 4.1. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
