[Development] RFD: Removing environment variable support from configure
Oswald Buddenhagen
oswald.buddenhagen at theqtcompany.com
Fri Mar 18 15:44:14 CET 2016
On Thu, Mar 17, 2016 at 01:45:44PM -0700, Thiago Macieira wrote:
> Summary: if CXXFLAGS is set on the environment when you run configure, the OS X
> build breaks.
>
> This happened because we don't test the building while those flags are set.
>
> I'm proposing we drop even checking them (configure lines 556 to 580).
>
we (that is, you and me) already decided that we should drop that code.
i was just reluctant to proceed now, knowing that users will see major
buildsystem-related changes soonish anyway.
https://bugreports.qt.io/browse/QTBUG-42962 is closest to a direct
indictment of this misfeature, though there are other tasks where this
is mentioned peripherally.
https://bugreports.qt.io/browse/QTBUG-32530 shows that it is implemented
incorrectly as well. https://codereview.qt-project.org/151857 forms the
basis for fixing this.
there are also some tasks which stem from this not taking cross-builds
into account.
On Fri, Mar 18, 2016 at 09:51:38AM +0100, Olivier Goffart wrote:
> How then are we going to insert custom compiler flags?
>
as always: fork/hack the makespec.
well, actually ...
as it happens, that (mis-)feature was implemented a long time ago upon
my explicit request - unsurprisingly, to solve some very real problems.
back then, there was no git to make hacking the makespec as painless as
it can be now. not to mention that the approach isn't all that nice to
start with. so the idea was to be autoconf-like, as that's customary on
unix systems. however, it turns out that it has "side effect" ...
instead, configure needs to be fed these options explicitly. after all,
we already do it for a bunch of specific options: -I/-L/-l/-F/-fw. we
could add some more options like that, or alternatively parse variable
assignments like CXXFLAGS= and HOST_CXXFLAGS= on the command line - the
windows configure already does (or at least did) it for some things
(openssl paths, etc).
note that the approach still doesn't mix that well with the makespec
concept, which tries to be somewhat property-based (specialized
variables for particular purposes). there isn't much we can do about
that with qmake.
More information about the Development
mailing list