if source and build dir are direct children of the common root and we
are shadowing the top-level source dir, there is of course no trailing
slash to match.
Change-Id: I8a34a6a72d16cb21d77d056e037235af9b32a008
Reviewed-by: Davide Pesavento <davidepesa@gmail.com>
Reviewed-by: Andreas Hartmetz <ahartmetz@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The return type of isActiveConfig is a boolean, so return that when
host_build is queried.
Change-Id: I6d1420b49b09e51442c4b2d482e2f19b165081d8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
everything in the projects should be normalized. only the makefile
generators need to adjust it to the native form.
Change-Id: I06a4e997f32134d13949ec4a9dd1b44367aab7cb
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
otherwise a cache/config in an aggregator project may unduly hide the
mkspecs/ of the aggregated project from qmake's view.
Change-Id: Idb0b124de071822f8f55463d9f8a4d194ef3130e
qmake will now look for .qmake.super, just like it looks for .qmake.cache,
and the cache() function has a mode to write this super cache.
this allows the creation of aggregator projects like, say, qt5.
a notable difference to the normal cache is that this file is *not* added
as a dependency of the Makefile. this means that modifications done by
later sub-projects will not cause a re-processing of earlier projects, and
consequently that one should be cautious regarding what information to
store there.
another notable difference is that this file is read *before* the spec,
so the spec can use the variables from the cache without resorting to
$$fromfile() & co.
Change-Id: I4807b6d34014261fa9eebd6f0ae128b802d86691
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is the source dir equivalent of .qmake.cache and can be checked
into the repository. it can be used to make project-wide settings, or
just to signal the presence of an mkspecs/ directory.
Change-Id: I5f1cebad2aa2a89e78089341b2051613b6b7a613
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this allows the creation of aggregator projects, like, say, qt5.
this is not expected to have a negative impact, as no project could
reasonably expect a nested .qmake.cache to *not* take effect - in fact,
if the project was processed stand-alone, it would already use it.
Change-Id: I33f2935d309baba7e95465f2fefb8231c4f03eda
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>
properties are now split into a write location $$[FOO] and a read
location $$[FOO/get]. the write locations are hard-coded and configurable
via qt.conf/Paths as before, while the read locations are configured via
qt.conf/EffectivePaths.
this finally provides a clean solution to the problem that during the qt
build itself tools and libraries need to be taken from somewhere else
than they are installed to.
Change-Id: I956c43bd082afd465e690fe75d0bee3c2c0f7c25
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
returns the list with the order of the elements reversed.
one can easily implement this with existing functions, but this is way
faster and more readable.
Change-Id: I12d306eb9fe58fc332622274ea6b658192529491
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
to be used in system() calls and when assembling EXTRA_COMPILER and
INSTALLS .commands by hand.
Change-Id: Id706cd56aa267a9fb4b14e3416692b4716fafa5b
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
just exposes QDir::fooFilePath() wrapped into QDir::cleanPath()
Change-Id: I7a7644084825fd8092a9910ac20f695c4d9351f6
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
more or less QDir::toNativeSeparators(QDir::cleanPath())
Change-Id: I52deee1e8086559eda5833b387a0cf64d21cbcd9
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@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>
this quotes the elements of a variable in a way suitable for re-parsing
as qmake code.
Change-Id: I0e6ea2478c43b5aeff45f485a48ac8c86705dd4a
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this simply returns the keys of all variables in the context.
Change-Id: I0092f827744fcd257dfb9e7ca664c87c6f1cc763
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is equivalent to unix "touch --no-create --reference <ref> <file>".
QFile has no setLastModified() (even though QFileInfo has
lastModified()), so the implementation is low-level.
Change-Id: I6783e8f2613e168ad0c24e79e7384d5b2e4901ee
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this dumps the contents of a variable into a file. each element of the
variable is considered a line; line terminators are added. all missing
directories are automatically created.
Change-Id: Idafeb873cea64e6705c894b3ab0ef21df69e7170
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this function adds the current contents of the named variable to the
cache. this comprises populating base_vars and appending an assignment
to .qmake.cache. if no cache file exists yet, it will be created in the
current output directory (and inherited by subdirs projects). if called
without a variable name, only create the cache file if missing.
Change-Id: I1e81c2238aa6a5817a6ebbfb022e2b995c349363
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this bypasses the otherwise done insane word splitting
Change-Id: Ia9b8980bc0770de3999544a06d239f55fb34f801
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>
... and followup fixes.
this is not needed any more due to the breaking patch being reverted.
Change-Id: Ia3416fcc16ddece680efbd0322286a601879fa0a
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>
QRegExp matching methods modify the object, which we don't want to. In
particular, when we receive a QRegExp from the user or we store in a
context that might require thread-safety, make sure we make a copy
before using it.
QRegularExpression has no such shortcoming.
Task-number: QTBUG-25064
Change-Id: I6b2d2530238a7e04b44859664a2962f2f466ee30
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The nice side-effect of having Q_ASSERT use the condition twice is
that we break code that has side-effects.
Change-Id: Ia0b7ed2a8030c8e222612af95eb2d58671433110
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
QStringBuilder will be enabled by default so qmake should build with it.
qstringbuiler.cpp has to be compiled in just for the convertFromAscii
(The alternative was to build with QT_NO_CAST_FROM_ASCII, but that would
be too much work)
Change-Id: I1fbeed7ed8a9d3bc38ef591a687c50644980e2fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Commit 8e5eb1bddc introduced the assumtion that mkspecs are
immediately below the mkspecs directory itself. This is not true for
e.g. unsupported/blackberry-armv7le-qcc.
This commit restores qmake's ability to find the "root" of the mkspecs
collection no matter how deeply the actual mkspecs are nested.
Task-number: QTBUG-24665
Change-Id: I98faaf8e6ae7b8524277aea6c17e685e507e37b3
Reviewed-by: Sean Harmer <sh@theharmers.co.uk>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this makes the "sysrootable" properties more magic, with the raw
versions being omitted from the qmake -query output and automatically
falling back to the "cooked" variant if there is no sysroot set.
this makes the "normal" qmake -query less noisy. this will become even
more obvious when i add more "overloads" of the properties.
Change-Id: I08000986427264ec6238c8fe0a77f5cecdbf1201
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
there is totally no reason to call it unless the project is actually
used for makefile generation, and the excessive calls actually mess up
things.
Change-Id: Idb7912a5404f6054010d2f29cce820a167de4f6f
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
clean up the somewhat convoluted code paths which forced re-evaluation.
now that the spec+cache are evaluated in a completely clean context
anyway, there is no point in re-evaluating them for build passes.
Change-Id: I12279083238e9ca7028af97f45e2638c8dc715b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of initializing base_vars with the original's vars, initialize
vars itself. this has two consequences:
- there is no need to call read(0) to initialize vars
- one cannot usefully call the complex read() anymore, as that would
re-initialize vars from base_vars
this is much closer to an actual copy than the previous "seeding with
existing project".
Change-Id: Ib007bc5b779aedb680a27329aa578f7c604a4308
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
load()/include() with a target namespace would inherit the current
context. however, if you source a project with all bells and whistles,
this makes completely no sense and may be actually counterproductive.
infile()/$$fromfile() would have interited only the functions from the
current context. that was only a hack to support abusing them.
Change-Id: I2e992b923d9e5b0e5056001ca49b35de573abc63
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is a hack from the times when these functions were (ab)used to
inspect proper project files, but the inclusion was done with a clean
project, so that the included files did not have any functions to work
with.
Change-Id: I19925e8ead597ca38df040000c183e368b32c06d
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>
don't inject the build pass specific variables into the project even
before evaluating the .spec file and the .qmake.cache. they are not
supposed to base configuration on that - feature files should do that
later.
the immediate advantage of this is that base_vars is never manipulated
upfront any more, which allows for cleaner setup paths. also, we can do
more caching of the spec+cache contents.
Change-Id: I19d7f8bec1fb7c3b54121e26794340b287055ebf
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
