In ancient times, the existence of QMAKE_RUN_CXX_IMP determined the
use of implicit rules. The code path for implicit rules was turned
off in 2006 (0287fe3c), which probably was a refactoring artifact.
Later, implicit rules were enabled again using a different approach.
These days, the non-existence of QMAKE_RUN_CXX determines the use of
implicit rules.
We remove the dead code path now and rely on the latter condition.
One part of the dead code is a feature that turns off inference rules if
the OBJECTS_DIR is set or source file names do not match expectations.
If somebody ever missed this, it has been reimplemented otherwise.
Or not.
Change-Id: If3ce9904d9c1df6e4048c58c2452854cce7fa206
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
instead of having each generator do its own magic (little surprisingly,
with different outcomes), add "stuff" to the search path in one place
used by all generators. this has several consequences:
- (unless disabled via CONFIG+=no_include_pwd) $$PWD is now consistently
prepended by all generators. most notably, this was entirely missing
from the MSVC generators (both nmake and VS) - despite them needing it
most. this also affects Xcode projects.
- $$OUT_PWD (if different from $$PWD) is now added right after $$PWD,
not at the end. this precedence clarification only makes sense, given
that qmake tries to make shadow builds as transparent as possible.
- the qmakespec's dir is now consistently appended. the UNIX and PBX
generators prepended it, while the rest already appended. few files
actually include qplatformdefs.h, so having it late in the search path
seems reasonable.
- the effect of CONFIG+=depend_includepath is now fully consistent with
the actual include path.
Change-Id: I5f7570183351ade29342ea74fef706a0738842bf
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
neither qmake_getpwd()'s return value nor a fileFixify()'d version of it
can be empty.
Change-Id: Ic3b7d20becc57209b9dbe71ad9dc8e7547d435b1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Running 'make distclean' should remove all files generated by qmake,
including .qmake.stash/super. These files are considered owned by
a particular project (and hence a candidate for distclean), if it
lives in the same directory as the output dir of the project.
Task-number: QTBUG-42678
Change-Id: I224e9bac039eeacb6561e18acc7f8e867da5dab8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
A typo caused qmake to stop output dependency information
added by the depend_command clause.
Task-number: QTBUG-13334
Change-Id: I00fabc87438ce94e80341e6f88aa2e0eaab57e19
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Qmake tried to extract the actual executable part of an
extra compiler's commands and depend_command value and
then "fix" it by replacing the directory separators in
it with their local versions and calling QDir::cleanPath
on it.
This misfeature was implemented incompletely and led to
unexpected results (see the numerous attempts to fix
QTBUG-16372).
The user is responsible for passing a correct command by
calling the shell_quote or shell_escape functions if
necessary.
Change-Id: Ic4bfe9eeb697775cd99c865e7a9d335e63605dea
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
it needs neither native separators, nor a trailing separator.
the QMAKE_PKGCONFIG_INCDIR default was already ok.
Change-Id: I1048b3870fd3ca09aa76b41aecda7d90402aa64a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This variable works like CLEAN_DEPS, but applies to the distclean target.
Change-Id: Ia30e8932b9acd6529298728dd5d0e038b0208d66
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This commit will make qmake use -isystem automatically for any
compilers that declare support for it for any paths that are listed in
QMAKE_DEFAULT_INCDIRS.
Change-Id: I36fefc6d5bba61671f65669f0ea42704b3c3cf31
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the respective code was removed in 375edf7
Change-Id: Ie31ef4bc8970b5396f50f1c4963f378df816242a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
it's bogus in the first place that the meta files contain windows paths,
but straightening that out is a prohibitive effort. so instead generate
additional s/// commands which take care of these paths.
fwiw, the generated s///i command is a gnu extension. but as we are
doing this on windows only where we are using our built-in sed command
anyway, this should be fine.
Task-number: QTBUG-33794
Change-Id: I46fcc598db12816ee56b5371ab184f6277eb3a22
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
that means further detaching the generation and installation of debug
info from the thing calling itself A Debug Build.
Task-number: QTBUG-32412
Change-Id: I4d79d1ae4806c8e4a2d6a7ccd030fb88385dd7d4
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
In particular this triggers in some cases of package building
where we are using a Qt version which for some reason has
forward slashes in its install prefix. Any mkdir command
run with this Qt build will fail because only backslashes are
recognized as path separators.
Task-number: QTBUG-34886
Change-Id: I2f957c6d348852ec555a67a35ae39921523b7b3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Allows project files or mkspecs to call qmake recursively using system()
with the right arguments, which we use to fix the ios default_post.prf.
Change-Id: I90d69e2b156bb0f0af1279188b11f81c84c24fb8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The fallback value is an empty string anyways.
Change-Id: I77a2d3ad275321cb8b2e059fb6359f921cbc697c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the problem is that there is no sed command on windows ... so build it
into qmake and invoke that from the generated makefiles. cmake does the
same, after all. ^^
Task-number: QTBUG-33794
Change-Id: Ib7077e18acbc5edd79f714c5779a5ed31ea6c093
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
A bunch of empty and never-to-be-used directories makes the build tree
noisy and harder to navigate.
Change-Id: Iebef91c82d58a8d6a0047fb5439d50eb6806f557
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
There was a mismatch of how we sanitized paths for dependencies of the
target and how those dependencies were sanitized (or not sanitized),
resulting in the target depending on 'some/path/foo.o' while the
extra compiler target was named 'some/path//foo.o', with an extra
slash. This confused 'make' enough to decide that it didn't know
how to build the dependencies for the target.
Change-Id: I181b86c291286cbbbb1f7b4c3b929a5f1dc163a3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The pattern ${QMAKE_ needs to be at the beginning of the line, or not
start with a $ (which would make it a regular qmake variable).
Also, it's fine that the variable is of the QMAKE_VAR_foo type, as
these variables are resolved at generator time, but are constant
and do not depend on the inputs. This means we have to replace
extra variables in the output.
Change-Id: I21ad24ae770f2137e2d5d92a20ee54e2f3f4ca06
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
as a side effect, this fixes the generators that were more bitrotted
(nmake and even more mingw).
Task-number: QTBUG-30644 #close
Change-Id: Iefa3f07125884412d091aa12b44935e5b1fb858a
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
replace() doesn't detach if there is nothing to do.
Change-Id: I845b585c766f44a670ca3af1fc11ba03e7317622
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... as that is the CWD of the command (since b139e7e96e5c).
leave the resolution relative to $$PWD as a fallback with a warning.
Investigated-by: Harald Hvaal <hhvaal@cisco.com>
Task-number: QTBUG-19352
Change-Id: I75de9444a647cd9e6f509e3d8eb3382dc985e5ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
makes for less visual noise and a tiny bit more efficient code.
Change-Id: I587707fa4e2dc9bead9435bf5caf3a98ab680725
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
These timestamps were useless and broken on non-ascii locales.
Change-Id: Iad08eb0f5dfd5e86f6451d6572365d0c080e6115
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This makes it possible to properly parametrize alternative compilers.
Change-Id: Iaf0961c47875ee16d815356f36acf5652577cdca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
unlike unix' mkdir -p, windows' md complains if the directory already
exists. the workaround is a quite complex command, so the so far used
concept for assembling the command line from pieces was replaced with a
single template. for symmetry, adapt the makefile existence check to the
new concept as well.
QMAKE_CHK_EXISTS and QMAKE_MKDIR_CMD were added, with hard-coded
fallbacks (ugly).
QMAKE_CHK_FILE_EXISTS and QMAKE_CHK_EXISTS_GLUE (introduced in 5.0.0)
are simply deleted again.
QMAKE_CHK_DIR_EXISTS and QMAKE_MKDIR remain for legacy reasons, as qmake
emits them into the Makefiles, and custom commands may rely on their
presence.
Task-number: QTBUG-28132
Change-Id: I3d049cb5d26947e5c3d102d0c2da33afb2a95140
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Janne Anttila <janne.anttila@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
d28073d9 creates a distinction between "mac" and
"macx". The latter is not set on iOS, which caused
MakefileGenerator::target_mode to be set to TARG_UNIX_MODE.
Check for the "mac" active config instead of "macx".
Rename TARG_MACX_MODE -> TARG_MAC_MODE.
Change-Id: I7192788c33f5723034ba76da2492379dd454f0ab
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
this makes it possible to properly parametrize alternative linkers.
Change-Id: Ia9cf574544a0259975470366d278b6c5dc747906
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
The Libs: line of the pkg-config files is constructed
by taking the name of the .pc file itself, and stripping
off the path and extension. However, the code which does
this does not handle path separators correctly when the
target OS and local OS are different. To get around this,
the custom string manipulation was replaced with a call
to QFileInfo::completeBaseName(), which can handle the
different path separators correctly.
Task-number: QTBUG-29700
Change-Id: Ia817b415d303b249f56fcc3d1f073cae99c43046
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
introduce the QMAKE_PKGCONFIG_FILE variable for that purpose.
this is another feature that is needed for a bugfix ...
Change-Id: I08f470e1b2b7dd318af9195330c15d813fcd55ef
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Metafiles such as .prl and .pc files contain paths that have to be
adjusted during installation. The same code is used for unix and
windows so move it into the base class.
Change-Id: I82db89ec83820a4fa0214ba15e7cd63438f6dc91
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
these variables are somewhat magic: they are relative to DESTDIR, and
they also specify the installation location relative to target.path.
the actual output directories are created by other code.
Change-Id: Iead3006057516f5a49b6fd4bd8996a062c984fce
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
nmake depends on a variable being assigned before it is referenced, so
just write it out to every Makefile as the very first thing.
this is nicer than the previous hack anyway.
Change-Id: I50f409919352f560f7ef6c848a2f7c51d1878148
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this is necessary for having a clean way to recurse even from leaf
makefiles.
the location where the variable is written in the makefile is somewhat
bizarre, but the code is so convoluted that finding a better place would
mean either a lot of duplication or a lot of prior refactoring.
Change-Id: I68e4cf7e3814f6c60b2e3421d69775c993dafb23
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this should be fatal, but so should be a lot of other conditions.
Change-Id: I0c2c0bb9590ea1e4d0eae76e29eda34915914217
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
DEPENDPATH merely says where to look for impliciit dependencies, not
where to find explicit ones.
fwiw, the other way round may be considered correct, but DEPENDPATH
exists for the sole purpose of limiting which paths should cause
recompilations, so it would be counterproductive to extend with with
VPATH.
Task-number: QTBUG-11912
Change-Id: I86450b5fd5aeb1f1b015b53f0adcd167ff4ce04d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The content in the prl file is not compatible with what CMake
expects in the value of the IMPORTED_LINK_INTERFACE_LIBRARIES
property. That property expects a list of IMPORTED targets or
full paths to libraries.
The prl file gives us a whitespace separated string of content
suitable for passing to ld, that is, it contains -L and -l content.
As this would take a lot of error prone parsing in cmake code in
order to resolve the content to a list of full paths to libraries
(which can be processed by any cmake generator), it's better to
remove the code until qmake is able to generate a list of full
paths.
Change-Id: I72fe8e862b7f3bd25a7f9a03db94d2e9b815d08a
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Clinton Stimpson <clinton@elemtech.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
The generated CMake files need to pass ';' separated libraries to
the IMPORTED_LINK_INTERFACE_LIBRARIES property, otherwise we get errors
such as this:
http://testresults.qt-project.org/ci/QtTools_master_Integration/build_00386/win32-msvc2010_Windows_7/log.txt.gz
(grep for QtCore5.lib.lib)
Rather than a naive and error prone replacement of whitespace, generate
the appropriate ';' separated content directly in the qmake prl file.
Change-Id: I8eb5e233a0318b57ec74b86d910583ff99c29415
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
This is an automated change performing the following replacements:
join\("(.)"\) -> join('\1')
join\(QLatin1String\("(.)"\)\) -> join(QLatin1Char('\1'))
join\(QStringLiteral\("(.)"\)\) -> join(QLatin1Char('\1'))
Change-Id: I9c9964703dedfdab6e7bfac80be22bd5570e2e49
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is a monster commit which does the following things:
- import the evaluator as-is from qt creator into qmake/library/
- integrate it into qmake's makefiles
- overwrite proitems.h with actual special types
- remove the parts of Option which are redundant with QMakeGlobals
- make QMakeProperty a singleton owned by Option::globals. the dynamic
handling so far made no sense.
- make QMakeProject a subclass of QMakeEvaluator, with relatively few
extensions
the changes to existing qmake code outside project.* and option.* are
minor. implementing the changes gradually would mean changing a lot of
code which will be just replaced in the next commit, so i'm not wasting
my time on it.
Change-Id: I9746650423b8c5b3fbd8c3979a73228982a46195
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is preparation for adapting to a new evaluator.
Change-Id: I6fc59f5525735754a00afa6629fbfe257e84db97
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this may have worked a decade ago, but now it only produces funny
Makefiles (and needs hacking main.cpp). the feature doesn't seem *too*
important, so just clean it out.
Change-Id: I50a60b0e30341f0b523e4a5731c770c9c1013f8b
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
don't read the spec from scratch for every library just to get
QMAKE_LFLAGS_RPATH. we can perfectly use our current project for that
purpose.
Change-Id: I4e408b3fd5de81652181df032aa53cd8f2f8f806
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
By putting object_with_source into CONFIG one could force qmake to
output each object file into the same directory as its source file
came from. This was a rather nasty work-around from Qt 3 times to
support source files with the same file name in a project.
Unfortunately this doesn't play nicely with shadow builds.
Change-Id: Ie79e14d36ba6eac4219edc14ea75ab6a96f9ea96
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
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>
this adds a .base "member" to the install "structure". if specified, only
this much is stripped from the front of each element of .files, rather
than the entire path, to obtain the target filename.
Change-Id: Ic39fcf71c4ad874ffabbbad113be9cdc6e3f7260
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
don't make a single string, but a string list which is join()ed in the end.
this is a tad slower, but the code is way easier to work with.
Change-Id: I1ff7168c2770998761a6081be8080c743ddc94a1
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
make a proper stringlist of commands, and join it in reverse order
only at the end. the reversal ensures that we can cleanly fold up
directory hierarchies we may build.
Change-Id: I9a241361588a6965283aec5258e1d622b35514e0
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
otherwise the second installation on unix would be bogus.
Change-Id: I162533ee262c6820e7e2d4710b5342cafecd9d59
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
we just determined that the file does not exist, so it's entirely
pointless to query its type from the file system. consequently, the
respective fallback branch would assume a regular file anyway.
Change-Id: I42590ffc2a5f650fb430a9398cb1859217ed4350
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the value is still re-processed numerous times, end each "exit path"
does own escaping, while not every path can deal with an escaped path.
Change-Id: I0bf4a043809bf4b7877d02e5d8dfe8f794a7dd00
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Remove references to an old compiler that has not been
supported for a long time. Also remove Borland specific
configuration flags which have no meaning elsewhere.
Change-Id: I3634a52b78f737ea972073e14c2b6669dcd0ae63
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the visitor-pattern like approach is not needed any more
Change-Id: I990db681cbeee91d89ecba97745a8104595247e7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it's more elegant, and more similar code is better.
Change-Id: I2b8b036cb70a932fd171e23cf7d3389188401924
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the unix and windows variants don't rely on it.
not making it purely virtual only because the project generator inherits
MakefileGenerator as well but does not need an implementation.
Change-Id: I80099b3f5d07cd037b408cf1099c58ff3a2904cd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this way QMAKE_LIBS{,_PRIVATE} can be treated the same as in all other
generators, which allows us to:
- make the windows generators' findLibraries() be more like the unix
version
- dispose of QMAKE_INTERNAL_PRL_LIBS handling while reading prl files
(because the output always goes to QMAKE_LIBS)
- as a side effect, QMAKE_LIBS_PRIVATE are not subjected to prl file
resolution any more, which is again consistent with unix - the
correctness of that needs to be assessed separately.
Change-Id: Ie9bc04d117eff6a7cde846677f98acf3c64aa6ee
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
it's a tad insane to expect the user to do that
Change-Id: I75c68f2a28656c9ba2e3fabcc79718b899b29ce7
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Don't hardcode the "qt_config" EXTRA variable and use QMAKE_PKGCONFIG_VARIABLES instead.
This allows qmake create the .pc files that are unrelated to Qt.
Change-Id: Ic72005e8819a15f6c50f3aaf79424a247fba20af
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
get the actual spec path directly from the project - the specs in Option
are not necessarily resolved.
Change-Id: Ia2bf2199c5269aa5b5a9d4c38de36171f25d448b
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>
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>
the only callers which used non-default arguments are gone now, so remove
the arguments entirely. this also enables us to re-enable result caching.
Change-Id: I62f76e17e531a4eeafddb9b29716ca0a0eb3dbea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the specs in Option are now only fixifiable absolute paths if an actual
path was passed on the command line - otherwise these are just names,
and we should pass them on verbatim.
Change-Id: I5b3535dadf2d6b2b3116331e6636f6e363a5361f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
instead of making the "real" targets depend on the makefiles, add
conditional makefile generation to the targets themselves.
this causes makefile generation to follow the recursion order determined
by the project, which is important when dealing with prl and module pri
files.
a side effect of this is that qmake and make calls are interleaved now,
which is entirely different from a 'qmake -r' run.
on the downside, calling make with multiple targets which operate on the
same subprojects without prior makefile generation will make a mess, as
the qmake calls will be racing. this should be no problem, as qmake does
not generate recursive targets where this would be useful - at least by
default.
it is not sufficient to just order the creation of the makefiles
non-recursively (e.g., by using gnu-specific order-only-prerequisites),
as an interrupted and subsequently resumed build would happily skip the
nested makefiles.
workable alternative approaches would be walking the entire tree in a
pre-pass to ensure makefile presence (which is incredibly slow) or
creating additional stamp files only after recursing and having the
makefiles depend on them (which is ugly).
Task-number: QTBUG-23376
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Change-Id: I88d3e7610215677d362026de316513d3bea04b06
instead of hard-coding platform differences, use a variable.
Change-Id: I20e98811ad5f07429148c6f88aedbabc3ba58fff
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
no point in entering the outdir and leaving the indir.
this doesn't really matter except for the obsolete borland generator,
but whatever.
Change-Id: Ieb4e4c549ebd65f99e4d00819c52822968b060a4
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the code above already deals with the differences
Change-Id: Ifb799e46f5187e7bd3d0f0169e868ad267bcfe23
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
no need to define an obscure variable for it. just inline it.
the assignments are left in for compatibility with hand-written commands.
Change-Id: I9bc3914e2c4116f3b8fe00a421ca0f036bb7e214
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
so far it would rebuild the makefiles one level down only, which is
somewhat arbitrary and not really helpful.
Change-Id: I5fe01f379ecc4b210610a674d7df7dfc18131eef
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
that's consistent with other projects. 'qmake_all' can be used for
recursion.
Change-Id: Ie6d620f7a3e0e28d3f2f82f01ca94c2f46137c68
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
$(MAKEFILE) is our own file, and using it would wreak havoc if it was
named anything but Makefile.
Change-Id: I51cae2014a85399b409f18788f864ff2a82e493e
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>
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>
make_first really means the same, as the default target is 'first'
which immediately invokes make_first.
as a nice side effect, this fixes ALL_DEPS not being used by the subdirs
template's default target - make_default wasn't special-cased in the
right place, while make_first is.
Change-Id: I946cea3b2dae198eda61d31dbd19c6ccd15deac7
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>
219a688ac1 added the version extension
which only occurs on the DLL import library.
Change-Id: Ie913adf039d7f3a9aadf43f4af014289a8aeacbe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Hib Eris <hib@hiberis.nl>
this was a somewhat magic support for sysroots, automatically rewriting
a number of path-holding variables. this was (as usual) completely
undocumented, extremely fragile, and we are coming up with something
better now anyway.
Change-Id: I045910f532cb3efc839ea81c7a48f8db695e4092
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 being a variable added to the makespec (via qconfig.pri),
QT_SYSROOT is now a property.
the QT_INSTALL_... properties are now automatically prefixed with the
sysroot; the raw values are available as QT_RAW_INSTALL_... - this is
expected to cause the least migration effort for existing projects.
-hostprefix and the new -hostbindir & -hostdatadir now feed the new
QT_HOST_... properties.
adapted the qmake feature files and the qtbase build system accordingly.
Change-Id: Iaa9b65bc10d9fe9c4988d620c70a8ce72177f8d4
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
The libName that is used in pkgConfig files should include the
TARGET_VERSION_EXT.
This is needed because in Win32MakefileGenerator::fixTargetExt(),
the TARGET_VERSION_EXT is added to the library name.
In Win32MakefileGenerator::processVars(), if TARGET_VERSION_EXT is empty,
it is set to VER_MAJ.
On platforms != Windows, TARGET_VERSION_EXT does not seem to be used.
We probably got away with this so far because pkgconfig files generation
for win32 was just added in 4.8 and nobody uses them yet, and because on
platforms != windows the TARGET_VERSION_EXT is not used.
Change-Id: I56f239e389f0ef926030e4c2376cadd92c4f673c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
It was the result of miscoordination between Andreas Holzammer and me,
duplicating the functional change of commit
ea2c9f764f.
This reverts commit 8b7a9b4898.
Change-Id: I9a47746c1c12ca00b2dc5c5d50e99f9bf990e3f7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
qmake-generated Makefiles since 4.6 (according to bug report) contain
recursive qmake invocations with absolute paths to .pro files, where the
absolute paths are not escaped.
Task-number: QTBUG-11776
Change-Id: I49772c7d9147efea3bb7b9623c61d92aa0bb6857
Reviewed-by: Jonas Gastal <jgastal@profusion.mobi>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
When installing extra binaries the paths where not being escaped,
causing stripping and deleting to fail when dealing with filenames
that contained one or more spaces.
Change-Id: Iba4517b1110f6af30f7e2662cb86024a8b7b81f7
Reviewed-by: Kurt Korbatits <kurt.korbatits@nokia.com>
Reviewed-by: Lincoln Ramsay <lincoln.ramsay@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this should make the evaluator quite a lot faster. the total win for
qtbase/src is only 6%, though.
i made some effort to avoid that output files get randomized. however, i
didn't bother to keep debug output sorted.
Change-Id: Id9cef4674c0153c11ebbb65cb63bf8c229eb56e3
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
This solves the problem of two source files in the same project
having the same name, which ends up with colliding object files.
It also solves issues with moving files around in the source tree
when the GNUmake option is used together with gcc_MD_depends,
where the dependency file would end up with a dependency to the
old source location.
We already have object_with_source option, but that does not play
nicely with shadow-builds. The new option tries to keep the same
hirarcy in the output dir (while still respecting OBJECTS_DIR),
as the sources. Any source with a path outside of the root project
directory (absolute or relative, ../../foo.cpp), will be put inside
the objects directory with the full path appended.
Change-Id: I0c96291974f4801f4c55a26485d512b15c144c00
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Extra compilers may define a depend_command that's used to generate
dependencies for each input. When GNUmake was enabled we failed to
run this command, which was affecting resource files, as resource
dependencies are handled by an extra compiler defined in resources.prf.
The result was that changes to resources included in a resources-file
did not trigger a re-run of qrc and subsequent recompile of the
resource object file.
We must always run these custom dependency commands, even when GNUmake
(and the extended gcc_MD_depends option) is enabled, as GCC is only able
to handle regular #include-type dependencies. Hence, the check for the
'include_deps' flag was removed from doDepends(), and the check for
GNUmake was moved to the one place where it still made sense -- when
deciding whether or not to do recursive dependency checking.
Change-Id: I5ddb75c873120c90f798808efc52e81500786301
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
And enable this configuration option for the resource compiler. This
results in a re-run of qmake whenever you touch a qrc file, which is
needed to keep the dependencies up to date. Otherwise you might end
up in the situation where you add a file to a qrc, edit the file some
time later, but a rebuild does not regenerate a cpp file and compile
that, so the final binary is stale.
Technically this dependency problem is present for all source files,
and qrc files are no different than any cpp file that you add a new
header #include to, or adding a Q_OBJECT macro to a header. To pick
up these changes we have to re-run qmake, so that qmake can run its
internal dependency checking, and any extra compiler dependency
commands.
The reason we're making this change for rcc files it that conceptually
people treat them as a "project" files, and expect them to behave similarly
to .pro or .pri files, in that editing the file will invalidate the
makefile. In practice this is often what happens when adding new
headers, as you touch the project file when changing the HEADERS
variable.
Task-number: QTBUG-13334
Change-Id: If69149678e7fba6d812d31dcc17877427f9a6122
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
Recursive QMAKE_EXTRA_TARGETS were omitting the `-f' option to make.
This would break in the case where the correct makefile was not named
`Makefile'. The included autotest demonstrates the problem.
Note that this was fixed for normal targets back in 2005
by faac7bd178654fd67a6f3f9cf4f6f2605071448d (p4 202370), but was not
fixed for extra targets.
Reviewed-by: ossi
(cherry picked from commit 96a3bf7a8bbc1e5361e16cbeeceb4be674b88c30)
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
