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>
Especially for header modules we don't want a 'Libs:' entry in their
.pc file.
Task-number: QTBUG-75901
Change-Id: I39037d3132e39dd360532e1425f794ebec28e0bd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QMake code like
rplc.match =
QMAKE_PRL_INSTALL_REPLACE += rplc
led to the generation of invalid sed calls in the Makefile.
It is already actively checked for empty matches, but if *all* matches
are empty, the sed call looks like
sed foo > bar
which is invalid.
Task-number: QTBUG-75901
Change-Id: I173ed99826414dcf06253a15a247f7d067ee3977
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the whole value of 'name', not just the first element, and also
replace variables like ${QMAKE_FILE_IN}.
This fixes the file_copies feature (COPIES) for Visual Studio
projects, because for every entry in COPIES an extra compiler is
created with a name 'COPY ${QMAKE_FILE_IN}'. Before this patch the
name and the generated file filter would be just 'COPY'. However,
duplicate filters are being skipped by the VS project generator. All
but the first COPIES entry was ignored.
Fixes: QTBUG-76010
Change-Id: Icaa5d2cb8d88ae3ef8ce86220198bca1b9e673f5
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Invalid SUBDIRS values like
SUBDIRS += foo \
bar \ \
baz
would produce a Makefile with a sub-- target that will call the make
on the same Makefile again recursively, letting make run forever.
Ignore values like this and print a warning message.
Fixes: QTBUG-76068
Change-Id: I6ca0f8c8238249f1be02d8c311b4c148fd80e707
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The qmake code to read output from dependency-generation was adding
QByteArray values to a QString, thereby tacitly converting from UTF-8;
this is misguided. Hopefully, the command emits its output in the same
local 8-bit encoding that QString knows to convert from.
Simplified needlessly verbose loops (that violated Qt coding style) in
the process.
Fixes: QTBUG-75904
Change-Id: I27cf81ffcb63ebc999b8e4fc57abdb9a68c4d2b3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Information about header files is cached by qmake. The key is the
filename of the #include directive. For system includes (<stdio.h>) this
is unique, according to the search order in INCLUDE_PATH.
For local includes, given as "foo.h", there may be name collisions. Usually a
compiler first searches in the directory of the current file (stored in the
sourceDir variable), and only in case of a miss the INCLUDE_PATH is
considered.
The dependency generation now distinguishes local header files by their full
relative path. This is implemented by forcing the use of the full relative
path as key into the SourceFiles data structure if the flag try_local is set.
Change-Id: Ifd75325b53496824054595f7fc98d71bbd9d8aa6
Fixes: QTBUG-72383
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This fixes the "could not parse compiler option" warning when
generating VS project files.
Fixes: QTBUG-75275
Change-Id: Idd98ae5fdb8ebf5a4e311cbb6cd3ed1daba74ca4
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
When installing directories, QINSTALL must not ignore contained hidden
files to be consistent with the old INSTALL_DIR.
Fixes: QTBUG-66835
Change-Id: I3a7c952dcac9732d5b17c5a258f87ca277b388d2
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
...like the install commands before Qt 5.9 did.
This ensures consistent permissions. Also, we can throw away the code
that took care of removing and re-adding the read-only flag on Windows.
This reverts commit a0b5d6e60f with the
addition of preserving permissions when copying directories to properly
install app bundles (QTBUG-74912).
Fixes: QTBUG-74733
Task-number: QTBUG-74912
Change-Id: Iee6d7c5e86787dd3ada5e5e9441209d418100b1f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This reverts commit 3cdf46059a.
It seems change is causing regression & is reverted now to be able to
proceed with releases
Task-number: QTBUG-74912
Change-Id: Ib2365b96ee98fbbcc8853cc7f8726c157c1913a7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
...starting with Qt 5.0.0.
The text is manually inserted there, because \since does not work
within sections.
Task-number: QTBUG-74737
Change-Id: I0fe2d0a113d48be0266030c8466b062c6f743aab
Reviewed-by: Robert Szefner <robertsz27@interia.pl>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
For applications that set VERSION the installation targets of pdb
files were wrong in qmake's nmake Makefile generator.
Replace code that tries to reconstruct that target's versioned
extension with TARGET_EXT which already contains the fully resolved
target extension.
Fixes: QTBUG-74265
Change-Id: I9553a5f70170e077a59c866079ae51647ae80bef
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
...like the install commands before Qt 5.9 did.
This ensures consistent permissions. Also, we can throw away the code
that took care of removing and re-adding the read-only flag on Windows.
Change-Id: I06bc3af8817f18c016119fbcb7360800d6c129bd
Fixes: QTBUG-74733
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Commit 2327944d added the QMAKE_DEFAULT_LIBDIRS to the library search
paths without taking care that explicit library search paths should be
inserted before system search paths.
Copy the behavior of the UnixMakefileGenerator, esp. of commits
5bc9541e and e185f343.
Fixes: QTBUG-73959
Change-Id: I7e951f432bb5f71ce4bcdb18b7102b4380441181
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
QMake's strategy is generally "pretend everything is Latin 1", which
basically equals "do 8-bit pass-through". Change the handling of
QMAKE_SUBSTITUTES input accordingly to avoid conversion losses when
converting from and to UTF-8.
Fixes: QTBUG-72130
Change-Id: Id903bbd2afa99708c92fd09fab3db944aa819a94
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Visual Studio doesn't support files being in multiple filters and
refuses to load such projects. Source files that appear in variables
that are mapped to file filters (SOURCES, TRANSLATIONS, ...) must not
be added to a second filter if they are input for an extra compiler.
Fixes: QTBUG-74004
Change-Id: Id2d752059c98d04e8154a7848c91f29a94bd092a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Instead of hardcoding the target's extension to ".exe" we should rely on
target information available in Visual Studio. $(TargetFileName) is
documented as "The file name of the primary output file for the build
(defined as base name + file extension)." so it can be used instead of
$(TargetName) together with ".exe".
Change-Id: I103d8d13456910617b2d53c9c8f4e2935eb93015
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
MSVC managed to trigger the this != &other assertion in
QString(const QString &other); so just skip creation of the
intermediate string in the function whose body tripped over this.
Change-Id: I687003cfc588531018c6069863ce2a76078c8e3f
Fixes: QTBUG-73802
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][qmake] A new feature "cmdline" was added that implies
"CONFIG += console" and "CONFIG -= app_bundle".
Task-number: QTBUG-27079
Change-Id: I6e52b07c9341c904bb1424fc717057432f9360e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
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>
IoUtils::isRelativePath() didn't attempt to consider UNC paths, due to
a belief that qmake fails on them so badly that it wasn't worth the
extra code. However, it turns out Qt Creator's copy of this code does
need to take this into account, so start the change off in qmake's
version so as to keep in sync.
Task-number: QTCREATORBUG-21881
Change-Id: I3084b87c1d3ca6508255e94e04ac8db3ceaebb7e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QMake ignored every extra compiler that sets variable_out and whose
output does not have a builtin compiler (C++, C).
What the code wants to achieve is to ignore extra compilers that put
their output into variables that are handled "somewhere else already",
e.g. are in the otherFilters list. Evidence for that is to be found in
the addOnInput == true if branch.
Task-number: QTBUG-71283
Change-Id: I8c1d76febccacb450cd14ad7a1f4b87726832312
Reviewed-by: Brett Stottlemyer <bstottle@ford.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Use xilink for ICC and lld-link for Clang.
Change-Id: I13c74339ae9e3e5c97210afd20a53c7e474b873b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the user changes the .pro file, the Makefile is supposed to be
re-generated by calling qmake again. NMake however lacks a "Makefile
remake feature" like GNU make has.
The generated Makefiles for nmake however have already a proper
Makefile target that can be used to re-generate the Makefile. What was
missing is the dependency from an entry-target in the meta-Makefile.
Now changes in the .pro file trigger a re-generation of
Makefile.Debug/Makefile.Release when calling nmake without target
arguments or with "debug" or "release".
Fixes: QTBUG-29193
Change-Id: I9f2dd5deba4a043ab6c9502bb0b0ba83dc843612
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
On macOS, if an extra compiler returns a framework include via its
depend_command, we must resolve it properly.
For example, the uic extra compiler might return an include
"QtQuickWidget/QQuickWidget", but the actual header file is located in
"QtQuickWidget.framework/Headers/QQuickWidget".
Fixes: QTBUG-72641
Change-Id: I42f11c74d01c88db8a32025b7f04d9ad50b2d08b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Factor out a resolveDependency method.
We will enhance it in a subsequent commit.
Change-Id: I4eead8bd03066c2ccbc9d9276acbc9f6c3bc6b97
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Default libdirs are never added to the modules' LIBS and if
Qt was configured to use one of the default libdirs, module
might end up without any path to search for its prl files.
Add default libdirs to the search path similar as it's done
in unix/makefile generator.
Fixes: QTBUG-72855
Change-Id: I43c5bae0d54ba9427ab0ad3eab61ba0c4e2cbde8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
rather than reproducing vcvarsall.bat's functionality as hard-wired code
in the nmake generator, just invoke the actual script from
toolchain.prf. this is much easier, more future proof, and - critically
- makes the detected variables available to configure's new library &
header search facilities.
[ChangeLog][Important Behavior Changes][qmake][WinRT] Cross-builds will
now ignore pre-set values of %INCLUDE% and %LIB% when building target
executables. If necessary, use configure's -I and -L switches when
building Qt, and pass QMAKE_INCDIR and QMAKE_LIBDIR on qmake's command
line when building own projects.
Change-Id: I36f53e8880d6523f3f6f7a44d40d87d04bd06854
Reviewed-by: Thomas Miller <thomaslmiller91@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
because QMAKE_EXTRA_VARIABLES sometimes just ain't enough.
Change-Id: I739e5b6510e4701ca0a86834e4f9a978d7ef1cf4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Hardware and camera button handling are phone specific APIs we no longer
support in Qt.
Change-Id: Ib11f894a426b8e4b71acf24876437ddab2cea548
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
... so we don't get into situations where a target has a relative path,
while another target depends on it with an absolute path.
Task-number: QTBUG-36768
Change-Id: Icc5b249914bb3f095f4a6542c30bacf5ea6f9ec9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since some files are still executable (such as bash scripts) then they
should not get strip called on them when installing in those cases.
So by adding .CONFIG = nostrip, it indicates that strip should not be
called on this.
Fixes: QTBUG-60751
Change-Id: I19d502c07644daf9d487a8817c8e57d96eedab60
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
this makes no difference whatsoever, because qmake isn't actually built
in a namespace, but it makes the new qtc code model happy.
Change-Id: I70ad8e16cceff73276a821219fc80bab365954b5
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>
Consider the following source tree:
foo/narf.cpp
bar/narf.c
bar/gnampf.cpp
The .pro file has
SOURCES += foo/narf.cpp bar/gnampf.cpp
The file bar/narf.c is not supposed to be built for whatever reason.
QMake's nmake Makefile generator generates inference rules of the form
{.\foo}.cpp{debug\}.obj::
...
for every source subdirectory and every source file extension.
Thus, we have
{.\foo}.cpp{debug\}.obj::
{.\bar}.cpp{debug\}.obj::
{.\bar}.c{debug\}.obj::
Depending on the exact execution order of the inference rules (which
depends on the names of the files) the latter rule might get picked,
and we're erronously compiling bar/narf.c even though it's not
referenced in the .pro file.
Conclusion: QMake's detection of conflicting source files must
consider the base names of source files, and not the exact file names.
Fixes: QTBUG-72059
Change-Id: I50c2725ae2a7421053369a10680230f571af00ea
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
'=' cannot be handled in the same manner as other "critical" characters
as no amount of backslashes will escape it. Use a variable instead.
The documentation for nmake suggests that '=' in file names is not among
the "Special Characters in a Makefile". Therefore, we assume nmake can
handle it and don't escape it.
Fixes: QTBUG-67262
Change-Id: Ib60f808d7d4e981c98f7d8bf2075d55b2b7f3b7d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Michael Brasser <michael.brasser@live.com>
The read from a QHash needs to be protected too if other threads are
writing.
sync-up with qtc, no actual effect on qmake itself.
Fixes: QTCREATORBUG-21416
Change-Id: I75e5634e11b10056d6dbb6fdceef482ca2222ca1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from qtcreator/5f79b5d2e5e33321cdcd00362f0d6d9442a73ec2)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
