double quotes cause mingw32-make to switch from direct execution to going
through the shell, so avoid them.
Change-Id: I05b71a050e425a1b327f747fab01755ff528ba0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
MakefileGenerator::init() fixifies the variable, so there is no point in
the windows generator adjusting path separators as well.
Change-Id: I9331631125ee16ce4d64e38153f3c67f2f78b16b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this is admittedly a rather improbable use case, so unlikely to have any
real world effect.
Change-Id: If98f0de90043525f0555f8ddf98f8b4352e5a0a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it always returned true nowadays.
an obvious followup effect is that the return value of parsedProBlock()
doesn't need to be null-checked any more as well.
Change-Id: I782785cab9b721a78a342a010921a73e642ebe7f
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
... because it also fixes the path, and we'll need the "plain" name later.
Change-Id: I86da8f53e44a68005c413c4b78b1b1682746e22e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
we (supposedly) fully support QMAKE_EXTRA_COMPILERS, so there is no need
for any special casing here.
Change-Id: I4e9d389320a3e5ad0acbf73823ff1e6f7b9c370f
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
it's debugging code which is used only once (if even uncommented).
Change-Id: Ie57347017dd24f4acecff2a7132f82898dea3122
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
more efficient use of string functions.
Change-Id: I3d95d6379eaab025b18449b706f93631a2132aad
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the path is processed, and afterwards fixForOutput()ed again. the first
call makes no sense (even if it registered some variables that are gone
in the second call, that would be pointless exactly because they are gone).
Change-Id: I251f1e4858bec36f3a7a9427c2ba78031b35a2d3
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
commands come already fully expanded and quoted from the project.
Change-Id: I239d5c305f5f65d32c832bc09bfd1c322051e149
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
no other generator does it. if it actually buys anything, it should be
re-instantiated differently.
Change-Id: I8431702ac7d558d65fd28a7f9e36bb49db2eb253
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the logic was such that if the bundle name already had the specified
extension which was not the default extension, the default extension
would be appended, too. i don't think that was the intention ...
now we simply put the default into QMAKE_BUNDLE_EXTENSION if its empty -
the variable is not used anywhere else where it would be expected to
preserve its emptiness, so this is safe.
Change-Id: Ied34d10f9fe60756bddc0037dcb2f1d3bbfd3e12
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
there is no reference to it anywhere.
Change-Id: I72403be6c8294d9b2e64075ebd428eba24d97097
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this isn't some fuzzy logic, the call sequence is well determined.
Change-Id: I1696b49ed687da83d2969efcfe23ac6565630020
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it never left the rudimentary stage. should it ever be re-added, it
needs to be done basically from scratch anyway.
Change-Id: I76858c8a2c90235f228f7a6e5a178a10a2669d37
Reviewed-by: Rolland Dudemaine <rolland@ghs.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
When there are source files with the same file name in different
directories of the project, then nmake's inference rules might pick up
the wrong source file. Note that this even happens when only one of those
files is in SOURCES. The existence of conflicting file names is enough
to cause hard-to-find build failures.
The usual work-around for this situation is CONFIG+=no_batch.
This is now done automatically when a conflict situation is detected and
a warning message is printed.
Task-number: QTBUG-13496
Change-Id: Icd81027407d3d489dbc50231e5ed8bcb91f8d2bc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
When using the cross-compiler toolchain for 32 bit on a 64 bit machine,
qmake generated a 64 bit VS project.
This was because qmake didn't know about the amd64_x86 cross-compiler,
and qmake did not use the first MSVC bin directory it found in PATH.
Task-number: QTBUG-43457
Change-Id: I50c6f7bb9afe44a58321c670d680dbcc7cd07223
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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 trying to load in ltcg.prf and cache the value.
Change-Id: If485ff68fc6ff9d9cf7009cd72d5e702d0199c7f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This just reindents and makes it easier to read what's going on.
Change-Id: Id0afcdfb8f468b4553bba8c5a572a1d0115b0886
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>
This is not used or referenced anywhere
Change-Id: I02e1aa76631627f64e5d1f9b36a13cdb5677e93f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
These mkspecs are not supported and no longer compile. Related support in
qmake has also been removed.
Change-Id: I7706dcfa5471e55e2ae3d580d65e9371e2c652d5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Tested with the Preview release of November 2014.
Differences to the 2013 detection and support:
- Option -Zc:strictStrings is present in both debug and release mode
and is passed to qmake's own build
- New warnings 4456, 4457 and 4458 (shadowing) are disabled
- Compiler supports -arch:AVX2
Change-Id: I9572ff4d4aded4004c1fa5d6f13ffee5462043d6
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
On Windows, the application manifest file can be linked with the
executable, to specify for example the requested privileges of the
application. On MSVC nmake, the manifest is already handled in
NmakeMakefileGenerator::writeBuildRulesPart, but it is not compatible
with MinGW. On MinGW, this manifest file has to be referenced in the
Rc File. This patch simply handles the existing variable
"QMAKE_MANIFEST" which defines the appropriate line RT_MANIFEST in
the RC file.
Task-number: QTBUG-42454
Change-Id: I921606e002ffe3801c537f30ac2365891f97d5c9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
