Change b274f656b8 enabled the use of a
response file for application building specifically needed when building
an application for Android on Windows. The same cause can happen when
building a library too with a lot of object files, so the command for
the link step can be too long. So we expand the functionality to be
used for libraries too.
Task-number: QTBUG-71940
Change-Id: Ia6d1943bf33f6decb53f6e71a8dc65310d2f20a1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Requires a third definition for the source-compatible but deprecated
version.
Change-Id: I260ae79f4547f99eed701b10e0b25222f81cd5ff
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Since commit 059172c6 precompiled headers did not work anymore on
macOS, because the ${QMAKE_PCH_ARCH} string was suddenly appearing in
locations where it was not replaced with the actual architecture, e.g.
the directory where the PCH files are written.
Fix this by replacing the whole file path and not just portions of it.
Fixes: QTBUG-79694
Change-Id: I925d4ee8980a0de3205a0e387a516a5c6f8cfa4b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
When building an application for Android on Windows it is possible that
the command line will be too long when doing the link step. So the code
for generating a response file is moved to MakefileGenerator so it can
be used by the other generators easily. The same variables used by
MinGW can be used elsewhere then.
Fixes: QTBUG-71940
Change-Id: I6c331d12e9541a90a4a95e0154d0ea1c056489bc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Precompiled headers were put in a directory which had exactly the same
name as the binary to be generated. This resulted in a failure with any
mkspec that used clang_pch_style. The g++-mkspec avoid this problem by
extending the directory name. This change adopts this technique for
clang mkspecs.
[ChangeLog][qmake] Fixed precompiled headers for the Clang compiler.
Fixes: QTBUG-72404
Change-Id: I471462e2bcb1e33f19d277c21acde0c04b1ffcd6
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
[ChangeLog][qmake] The syntax 'LIBS += -frameworkFoo', or
'LIBS += "-framework Foo"' is no longer supported. Use the
canonical 'LIBS += -framework Foo' instead.
Change-Id: I50fd02dbfa155a0b95859734486a92bd448e87c2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The root of the framework bundle shouldn't contain random files,
and doing so will prevent the bundle from being signable.
We still look up prl files in the root, to keep backwards
compatibility.
Change-Id: Ifd0bc3c6e7924e89eec54d3ef9368dfc95ed402c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This was introduced by accident in 4da47d0f.
Fixes: QTBUG-77429
Change-Id: Ic3d9052e1fc83dab5ed3b8725629588208b0d7bb
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
QMakeLocalFileName is not suitable for QList. Use QVector instead.
Change-Id: I5a3c4c8da14c0a920b5a57cba148ad68ac0f85a2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Libtool cannot cope with absolute paths in the dependency_libs entry.
We split absolute paths into -L and -l here.
Change-Id: I30bf11e490d1993d2a4d88c114e07bbae12def6d
Fixes: QTBUG-76625
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This undocumented option was introduced in
69c22301806b56d56cbe5f5076b889ba98e41a2b (old internal history, 2006) to
prepare some unspecified change to configure that was never done.
Change-Id: I60de731ac9bc6f6424c57574e59e9f6b4f6c5eb3
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Without treating -force_load as an option with an argument, we end up
leaving stray -force_loads in the linker line, resulting in build
failures when the following option is a random library then treated
as a file path.
Task-number: QTBUG-66091
Change-Id: I352c50ab67e32ef6b2b5c6a4f90455b20034e207
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The linker doesn't support -framworkFoo, so neither should we. The correct
syntax is -framework Foo.
Change-Id: I3f39ffc067871ce058542bf0068274b35f7b51f6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Those modules are TEMPLATE=aux, so they weren't triggering the file creation
here.
To make this work properly we have to:
- check for TEMPLATE aux in the right places
- add a dummy target to INSTALLS to actually trigger the creation
- initialize PRL_TARGET for aux templates
Fixes: QTBUG-75901
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Idce141629dd34287808bfffd159f92ac28c6c8b1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qmake automatically appends a dir_sep to a few directory paths (see
MakefileGenerator::initOutPaths), and various .pri and .prf files rely on
that. Anyhow, for non-MSys MinGW on Windows this creates a problem,
because mingw32-make will interpret the backslash in
OBJECTS_DIR = some_path\
to escape the following newline. We have been working around this
problem in various ways:
- winmakefile.cpp just removes the trailing \ for OBJECTS_DIR, at the
cost of not being compatible with logic in .prf/.pri files that rely on
the separator.
- winmakefile.cpp adds a '#avoid trailing-slash linebreak' comment for
DESTDIR. Anyhow, this does not seem to work for mingw32-make: If you
reference $(DESTDIR), the variable will contain trailing spaces.
- unixmakefile2.cpp duplicates a trailing \ for DESTDIR.
The last approach is now taken also for OBJECTS_DIR.
Task-number: QTBUG-75257
Change-Id: Ie8171a990a9ce1cfbf1b94037252ef2392313338
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
make it "last one wins", consistently with regular libraries. this
isn't really relevant in qmake, because the order matters only for
static frameworks, which qmake defines out of existence.
note that specifying frameworks by full path does not work, so we
don't need to amend 9d76beee5 in that regard.
Change-Id: Ib027109339e1b5973c577d69906b6daf83ba9611
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
because QMAKE_EXTRA_VARIABLES sometimes just ain't enough.
Change-Id: I739e5b6510e4701ca0a86834e4f9a978d7ef1cf4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... which are specified by full filepath, by making the de-duplication
consistent with that applied to libs specified with -l, that is, last
one wins.
the problem existed "forever", but it became more visible after the
recent configure changes.
fwiw, Win32MakefileGenerator is not affected, because it has the
opposite problem: it de-duplicates everything (including object files)
in "last one wins mode". it might make sense to change that as well.
Change-Id: Id7ef1d394fcc9d444450672c06a6f11af2b19eab
Reviewed-by: Robert Griebl <robert.griebl@pelagicore.com>
This will be the only options for Qt 6, so make sure the code compiles now.
Change-Id: I23f791d1efcbd0bd33805bb4563d40460954db43
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
it must end up in front of QMAKE_LIBS{,_PRIVATE}, but not of
LIBS{,_PRIVATE} (which are preceded by QMAKE_LIBDIR).
Task-number: QTBUG-61982
Started-by: Liang Qi <liang.qi@qt.io>
Change-Id: Id3de01ee0e9b66af02f79949aeb5a0eabd55363f
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
the early merging of LIBS* into QMAKE_LIBS* meant that we could not
interleave them properly. defer the merging until the points of use.
Task-number: QTBUG-70779
Started-by: BogDan Vatra <bogdan@kdab.com>
Change-Id: I890f98016c3721396a1f0f6f149a9e2b37d56d8e
Reviewed-by: Liang Qi <liang.qi@qt.io>
it's unused now, and just complicates matters. its interaction with
LIBS_PRIVATE & co. has always been a bit shaky. google produces no
public hits outside qt itself, so let's assume it really remained
internal.
Change-Id: I6606bbabd44f1b76d84e97219e155e38d6f1b3a6
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
this was introduced in 2002 supposedly for qnx4, but doesn't appear to
have actually been used ever. remove it, as it's in the way now.
Change-Id: I54dcabb61e1d3609a1e7a9fa4ff4b25509cfdb7a
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
instead of trying to reverse-engineer it from the final target including
extension and possible bundle path, construct the basename explicitly.
this avoids that we mangle the filename if the actual target contains a
period for some reason.
Task-number: QTBUG-70097
Change-Id: I0bae9f010ab82e258680830250f8e28656f09d67
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the variables are quoted correctly for commands, which is incompatible
with quoting for dependencies under mingw. so insert the paths as
literals, where we can control quoting.
this fixes building in directories with spaces, which i broke in
7c34e0a7b by using different quoting styles for deps and commands in the
first place.
this breaks the hypothetical use case where somebody wants to override
TARGET or DESTDIR (or DESTDIR_TARGET under windows) on the *make*
command line. not sure why anyone would do that - just do it at the
*qmake* level.
we did not get rid of OBJECTS, because that would cause significant
duplication in the makefile (not that it would matter too much, given
the dependency lists ...). this isn't a problem, because these are
short relative paths which are not expected to contain "funny"
characters.
an alternative would have been to change the variables' quoting and
eliminate them from the commands instead, but that would be
backwards-incompatible, because commands are "user-servicable".
for the same reason, we cannot get rid of the variables entirely.
Change-Id: Ic7592c7fc67d8b7d2b64de80808365cd1c3f79d0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
add a parameter that indicates whether the passed filename can be only
the basename of a prl file. if so, we can skip the other attempts at
interpreting the file name. that's not only faster, but also clearer.
Change-Id: I6f6da3f4485216021282a08acaefb53e60e7242a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the code ensures that the path ends with a path separator, which is
unhealthy under mingw when the command ends with that path, because it's
interpreted as a line continuation.
the easiest fix is just duplicating the name of the moved file to the
destination side.
the cleaner fix would have been cleaning up the path separator mess, but
that's a more invasive change and doesn't seem worth it.
Task-number: QTBUG-69255
Change-Id: I338f8997b84ed7049b5665872dd25f90b9d4d16a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need to take into account the presence of a possible ',_debug' suffix.
Change-Id: I5655394b78723bbc6cc32e56849acc2366d288e2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the source file must not be written with an absolute path to the
makefile, as this won't match the name of the target which generates it,
thus leading to an unsatisfied dependency.
this is the proper fix for QTBUG-60413 and a bunch of others.
amends historical f173e217cd.
Change-Id: I28140351c4b4759de35e60daf63bc54b82d104ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.
Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
