instead of re-assembling a list from the variables, take the original
command line minus some explicitly stripped out options. this is way
less code and poses no synchronization problem between the two parts.
as a "side effect", variables obtained from $QMAKEFLAGS won't multiply
with each makefile nesting level, as the generated command line won't
replicate data obtained from the environment.
Change-Id: I5d1ce0f11efb338f60405529f9818910103b1b0e
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the feature was implemented for the abld/sbs2 generators only, and is
of course undocumented.
this reverts most of commit e795e61ef93f8080f9938ac49f2fca306644af85.
Change-Id: Ibd1726b036ce6c45f8e678ea996218f774f8aed2
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
it was used only for determining the path separator, so do that
directly.
the -macx option went bye bye, as it is redundant with -unix now.
Change-Id: Ib8344c042db56e05af75d263447311d4b43a3bf0
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
these are not actually used inside qmake since ever the code was factored
into moc.prf.
Change-Id: I545f4857ca3f0b4bf2439703700069ac67ad4ca2
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the project evaluator becomes oblivious of the target mode.
the mode is set up in spec_post.prf according to the spec.
$$QMAKE_TARGET contains the feature suffixes to search, and is also
contained in $$CONFIG.
the target_mode variable itself becomes private to the Makefile class.
Change-Id: I3c06d9dab536b753343cec6c5c491d3203e50bd8
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
it wasn't really wired, so the only effect it had was disabling the unix
scopes (despite an attempt to override that in the spec, which probably
worked before qt 4.6, and will start working again soon).
Change-Id: I95daff75b508edaf83a8a06fd327350acd62b124
Reviewed-by: Rolland Dudemaine <rolland@ghs.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
(some of) the generators are (moderately) x-platform, so it makes no
sense to nail the host platform to a generator (and thus a spec).
overriding the host platform is only a debugging mesasure anyway, so one
can use the (now undocumented) -unix/-macx/-win32 options for that.
Change-Id: If2a059f1feeb2c726e5838625ede1c7add829985
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
they have been deprecated long enough, so we can mess with them now.
don't make them set the target mode any more; the makespec can do that
autoritatively. instead, they can be used to override the host mode for
debugging purposes.
Change-Id: Ife5fdcf4f1b6b926901a80896ac92b7d821278d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
don't even complain about trying to use js-based feature files. we have
been doing that for long enough.
Change-Id: Ib58ec204322442c488e8d780989f26b1e32595ed
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
return the build directory corresponding to a given source directory.
this is the identity function if not shadow-building. if input lies
outside the source directory, return empty value.
Change-Id: I2d2a6b1112bd19989fe29cfe19a12d39a0d208c1
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
when qmake runs into the new option(host_build) command, it will restart
the project evaluation with a host spec.
the new default host spec is called default-host (gasp!). it is
overridden with the pre-exising -spec / -platform option, while the new
-xspec / -xplatform option overrides the pre-existing default spec.
specifying -spec but not -xspec will set the xspec, too, so the behavior
is backwards-compatible. same for the XQMAKESPEC override read from
.qmake.cache and the environment variable.
the cleaner solution would be adding -hostspec, to be symmetrical with
the override semantics, but that would deviate from configure in turn.
Change-Id: I4297c873780af16ab7928421b434ce0f1d3820da
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
We are now moving in the exact opposite direction.
This logically reverts commit 059200a44b.
Some adjustments were necessary to maintain the project root stuff.
Conflicts:
qmake/main.cpp
qmake/option.cpp
qmake/option.h
qmake/project.cpp
Change-Id: Ic14fa571cbbfe9ac159f92493e49741d70a87eff
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
merge them into before_user_vars. they are evaluated right after another
anyway.
Change-Id: I11859284b363fee01233f6e20989444fef711d0d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of messing with the Option singleton, add a way to inject
extra config values into QMakeProject.
Change-Id: Ia347dcc38af2c72913e30ebf5c2b4044f93b4f5f
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I07c66d95a9ae01a664cec17564995311fb78ec9b
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
there is no reason for doing that. there is even reason for *not* doing
it (the enums running out of sync).
Change-Id: Ieb7d015ca497a6675cc85da4c2e0af0c1533dd7a
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
qmake would look for mkspecs/ in the directory containing the current
project file. this makes completely no sense with recursive projects:
a) nobody would make per-project specs and b) specs meant to be global
would not be found.
consequently, we look for a project root when starting qmake and use
only that directory.
if .qmake.cache is found/set, we assume that to be the project root.
otherwise, we search for mkspecs/ the same way we search for the cache -
just to up until we find one or hit the root. if we are shadow-building,
search the build dir as well.
Change-Id: Ie66b189a40c21203d956e681cbef44a89f98cd17
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I11ef30a8227afed06e58e64e65809dba25e81567
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Tests will install under $$[QT_INSTALL_TESTS].
TESTDATA may be used to install additional testdata required by the
test.
The default install rule may be disabled by
CONFIG+=no_testcase_installs.
Change-Id: I204de60c8e844775906ffd016ca50bffbb414142
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The distinction between 'examples' and 'demos' is completely blurred at
this point. We've decided, with the SDK people, to scrap the existing
terminology in favor of the word 'example' only -- distinguishing
between code snippets, walkthroughs, "demonstrations" can be done
via keywords or some other method.
Removing QT_INSTALL_DEMOS from all .pro files in Qt is still in
progress.
Change-Id: I86fc0e40d54baa54c5641fc6acbd8b67e4ad2789
Reviewed-on: http://codereview.qt.nokia.com/1034
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
