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>
This change allows using custom flags for ar. For instance, it is
now possible to create a thin archive by setting QMAKE_LIB += -T.
This uses and extends commit d92c25b1b4
which served a similar purpose for the linker.
Change-Id: Ie1d6a0b957dc4809957726de00911c8d91647fab
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>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
The absolute paths of certain static dependencies can have spaces in
them. The _qt5_$${CMAKE_MODULE_NAME}_process_prl_file fails to handle
this, and simply replaces all spaces with semicolons, which obviously
breaks the list of dependencies, and a consuming application fails to
link with a message like:
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'
This change partially restores the functionality that was added in
102e1822ff specifically the part
that changes qmake to export an additional variable
QMAKE_PRL_LIBS_FOR_CMAKE. This variable has the same content as
QMAKE_PRL_LIBS except it uses a semicolon as a separator, so that
CMake can correctly parse the separate lib entries.
This is much cleaner than trying to parse the original QMAKE_PRL_LIBS
variable with a complicated regular expression.
Amends eda28621f6.
Task-number: QTBUG-38913
Change-Id: I1d18fb779606505bc92320d8ce13232c7022e212
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
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>
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>
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>
[ChangeLog][qmake] The CONFIG value c++latest was added to select the
latest C++ standard the currently used toolchain supports.
Task-number: QTBUG-75653
Change-Id: I22ddc9d293109d99e652b7ccb19d7226fca4716d
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>
Conflicts:
src/corelib/tools/qlocale_data_p.h
(Regenerated by running the scripts in util/local_database/)
src/gui/opengl/qopengltextureuploader.cpp
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Done-With: Allan Sandfeld Jensen <allan.jensen@qt.io>
Change-Id: I12df7f066ed0a25eb109f61c4b8d8dea63b683e2
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>
Added a sentence to explain how a .qmake.cache file influences the project root.
Task-number: QTBUG-21411
Change-Id: I97766edd96851f1c988ab07f842fb81a339e4ecd
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>
