The description of the project mode looked like this:
-project Put qmake into project file generation mode
In this mode qmake interprets files as files to
be built,
defaults to *; *; *; *.ts; *.xlf; *.qrc
The list of wildcards is incomplete. Unfortunately the file extensions
are defined in QMAKE_EXT_* variables in mkspecs, and the help display
code has no access to that data. This went unnoticed for quite some
time, and fixing this is too involved considering the gain.
Replace the text above with the static text below:
-project Put qmake into project file generation mode
In this mode qmake interprets [files] as files to
be added to the .pro file. By default, all files with
known source extensions are added.
Change-Id: I815a50957c05dccc45e1cd6657f568599d1911f6
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The conditions were wrong, they must compare against zero.
Also, use qstricmp to avoid the platform #ifdef.
Change-Id: I7e5ef1b9ae8e2e1d3d9ce90a645ee568b370ab57
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Having those characters in QMAKE_EXTRA_COMPILERS broke the generated
VS project file. They must be replaced by XML entities.
Fixes: QTBUG-1935
Change-Id: Iff1edbeabec4cedef777071682412970b7769f19
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
RC_FILE is not an internal variable that "rarely needs to be
modified". Mention that it's about Windows resources and link to the
corresponding section.
RES_FILE: Add link to RC_FILE and the more general section. Also
rephrase "compiled Windows resource file" to "Windows resource
compiler's output file" which is more precise.
Fixes: QTBUG-8709
Change-Id: I19c61e6a9505d45fc13fefbcd0ba9441191aa42e
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Kavindra Palaraja <kpalaraja@luxoft.com>
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>
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>
It conflicts with 'requires' keyword.
Fixes: QTBUG-77093
Change-Id: I85e8f530dd1e2bf9a31906dd6c5123b947235b01
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
ProFunctionDef is move-enabled, meaning its `m_pro` field can
become nullptr. Its usage in the assignment operator and the dtor
must therefore be protected with a check.
Amends 9c63ad562b.
Change-Id: I0c77b07dc83969565480bbb9d9fc80751d4246b1
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
This reverts commit 224a60989e.
Turns out that we cannot just untangle the determination of
source root and build root, because this breaks the assumption
that every .qmake.conf results in a separate .qmake.cache in the
build tree. QTBUG-76140 must be fixed differently.
Fixes: QTBUG-76907
Change-Id: I5c0a3719d5e00a0f1cacad51651b47c1f284d22d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This saves us lots of .toQString() and .toQStringList() typing when
qDebug()'ing qmake code.
Change-Id: I037e5e1816f2dcb6a20dec4c275f3d886f155ad5
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
'make clean' removed the import libs for DLLs which makes them quite
unusable. Move the import lib removal to the 'distclean' target.
Fixes: QTBUG-51977
Change-Id: I727d520435f88a83a7fb14cb0ad81f8fe7c6d61b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Fix clang warnings that are disabled in the default build.
Change-Id: I4e773a24884db94acdc6c295d3f66da07cd8a5bd
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
QMake searches a .qmake.conf file to determine the source root of the
project, and a .qmake.cache to determine the build root.
If a .qmake.conf exists but no .qmake.cache in the build directory is
found, a build root would be set that is only valid if the build
directory is at the same depth as the source directory.
The invalid build root resulted in the creation of .qmake.cache files
at "interesting" locations (e.g. high up in the directory tree), a
potential cause for even more interesting build failures in the
future.
Fix this by splitting up the loop that determined build and source
root. Both are now determined independently of each other.
Fixes: QTBUG-76140
Change-Id: Ib5c922b87879fcf2f076298a69abcdbc4e8587b3
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
