Adding the header path should fix the problem. Firebird 1.0 installs to /opt/interbase and firebird 1.5 in /opt/firebird, so both include paths should be added, even though it seems that 1.0 will be dropped as soon as 1.5 is stable (Bug 42518). A similar problem: Qt's build process autodetects available header files and includes the related db support. This shouldn't happen. I want Qt only to include the db's, which are specified by use flag, so if the flag isn't set, the option -no-sql-<driver> should be added. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Oh, just found out that my old Firebird 1.0 installation missed the symlinks to /usr/include, so only the second issue is a problem.
Qt will autodetect headers, but *shouldn't* explicitly build or include any plugins that aren't called for or added by the command line options.
*sigh* Of course you're right Caleb.
Glad to hear :) - I was getting worried that I had broken something.
One simple question: Why does the -no-sql-<driver> option exist then? Don't know much about autoconf/make, but I don't think there's always a complementary option!?
the configure script for Qt is a custom written one by Trolltech, it's not automake or autoconf based. Not exactly sure, but I think it has something to do with saved options in a cache. I think if you configure stuff on, then later rerun "configure" it will reload the saved options unless you explicitly turn them off/on.
Hm - that means this can affect portage when having noclean in features and changing use flags between two compilations. When I had problems with compiling Qt (like today), I have always to rm -rf /var/tmp/portage/qt* before compiling again, otherwise the compilation will fail for other reasons. I don't think this has something to do with it, but there are so much users having problems with compiling Qt/kde* ebuilds lately. Maybe it would be good to be more explicit. For me, the last qt/kde ebuilds, which compiled out of the box, where 3.1.* ones.
ok, I'll take a look at it when I get home tonight.
