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>
In MakefileGenerator::initOutPaths() we ensure that directory
variables end with a directory separator, except for DLLDESTDIR.
There doesn't seem to be a valid reason for this exception.
Remove it for the sake of simplifying the code base.
Change-Id: I60eb01b410161e6e1d147d76f044f5140a7573bd
Reviewed-by: Edward Welbourne <edward.welbourne@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>
Re-generation of the Makefile depends on a correctly set up
QMAKE_INTERNAL_INCLUDED_FILES variable. In debug_and_release builds
this variable is set up for Makefile.Debug and Makefile.Release, but
not for the meta Makefile. However, that's where the Makefile
re-generation target is located.
We now collect the contents of QMAKE_INTERNAL_INCLUDED_FILES for
Makefile.Debug/Release and use that for the meta Makefile.
Fixes: QTBUG-13334
Change-Id: I6124a91447d5c54d51680e23570c4e97f44e6a73
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
...because
- it calls the properly camel-cased member function buildArgs(bool),
which is slightly confusing
- it returns buildArgs(true) plus input and output
We also let it return only the arguments, excluding the qmake
executable. This is consistent with the function's name and saves us a
string replacement stunt at one call site.
Change-Id: I8bea65900bd51962962e4cfd425ffbc26e3a52fe
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Remove usage of the 'if (0 && ...)' pattern that was presumably used
to temporarily disable code paths. The disabling of the two code paths
was introduced in 356a677b386648710efc4db9a8a1b4a975f95c48 (old
internal history, 2004) and
0326e3511928d90329152b9b0493da76e9caa442 (old internal history, 2006).
It can be deduced that it's pretty safe to remove both.
Change-Id: I88aee65b1286701241b5b80fbac0c65cd99ecd5e
Reviewed-by: Edward Welbourne <edward.welbourne@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>
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>
Since commit 20e9422e we don't ignore exit codes when installing files
anymore. This patch does the same for meta file installation. We
really should be notified properly if something goes wrong here.
Task-number: QTBUG-18870
Change-Id: Ib6a20293380f400379b10ec767bf38dc74d5beeb
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
A recurring problem with the Q_NAMESPACE macro is that it declares
an object (staticMetaObject) in the surrounding namespace. That
object lacks any export/import qualification to make it usable
with shared libraries.
Introduce therefore another macro to work around this issue, allowing
the user to prefix the object with an exporting macro, f.i. like this:
Q_NAMESPACE_EXPORT(Q_CORE_EXPORT)
The old macro can simply then be rewritten in terms of this new one,
supplying an empty export macro.
Note that NOT passing an argument to a macro expecting one is well
defined behavior in C99 -- the macro will expand an empty token.
Of course, MSVC doesn't like this and emits warnings. As a
workaround, use a variadic macro.
[ChangeLog][QtCore] Added the new Q_NAMESPACE_EXPORT macro. It
can be used just like Q_NAMESPACE to add meta-object information
to a namespace; however it also supports exporting of such
information from shared libraries.
[ChangeLog][Potentially Source-Incompatible Changes] Prefixing
Q_NAMESPACE with an export macro may no longer work. Use the new
Q_NAMESPACE_EXPORT macro for that use case.
Fixes: QTBUG-68014
Change-Id: Ib044a555ace1f77ae8e0244d824ec473550f3d8e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
'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>
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>
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>
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>
Clang-cl couldn't find the header given to it by -FI when it isn't in
any of the included directories.
Additionally clang-cl 8 has a bug with exported templated classes with
inline methods that causes it to have missing symbols at link time. We
work around this.
Fixes: QTBUG-74563
Change-Id: I7becf05fa8edb07bd4cefe12bee3737e5e1dfa14
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The comment hints that it's fixing an issue in Visual Studio 2013, which
we don't support anymore.
In all supported Visual Studio Versions -Gm is actually deprecated
anyhow, and not set anymore by default. So I guess it's safe
to remove the special handling here.
Change-Id: I2e8ff85350ba651d9a763aabba7b6494ba88d82e
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
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>
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>
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>
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>
With Qt 6 in sight, people need to start moving away from
their deprecated APIs, as we want to remove them all in 6.0.
We are marking deprecated APIs with deprecation attributes,
but by default we're disabling deprecation warnings, making
them an opt-in by the user.
We need to do the opposite: make deprecation warnings enabled
by default, and have an opt-out define.
[ChangeLog][QtCore][Important Behavior Changes] Qt now
enables by default warnings when using APIs marked as
deprecated. It is possible to disable such warnings by
defining the QT_NO_DEPRECATED_WARNINGS macro. The old
QT_DEPRECATED_WARNINGS macro which was used to enable
this warning now has no effect (warnings are automatically
enabled).
Task-number: QTBUG-73048
Change-Id: Ie2b024fd667eb876b6ac9054cbbbc5a455cb9d5c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Also blacklist tst_QRawFont::unsupportedWritingSystem() and
tst_QGlyphRun::mixedScripts() on windows for now.
Conflicts:
qmake/generators/makefile.cpp
src/corelib/itemmodels/qstringlistmodel.cpp
src/platformsupport/fontdatabases/windows/qwindowsfontengine_p.h
tests/auto/corelib/itemmodels/qstringlistmodel/tst_qstringlistmodel.cpp
tests/auto/gui/text/qglyphrun/BLACKLIST
tests/auto/gui/text/qrawfont/BLACKLIST
Task-number: QTBUG-72836
Change-Id: I10fea1493f0ae1a5708e1e48d0a4d7d6b76258b9
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>
That's an undocumented Qt 4/3/2 remnant, start remove usages.
Fix incorrect include header in qclass_lib_map.h as a drive-by.
Change-Id: I939be2621bc03e5c75f7e3f152546d3af6d37b91
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
MakefileGenerator::initOutPaths should only do that: init out paths.
It's not supposed to modify the content of input variables for extra
compilers. Those get "fixed" in MakefileGenerator::init below the "do
the path fixifying" comment.
The first "fixifying" would turn an absolute path in SOURCES (input
variable for the moc_source extra compiler) into a path relative to
the output directory. The second "fixifying" would mess everything up.
Fixes: QTBUG-76097
Change-Id: I8c50ef33d097dba4a1db76144c70b0677beffb6c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Flesh out copy-and-pasted code into a function and adjust the coding
style on the go.
Change-Id: I9b8a87d6dd5c33cc1ed9f613fe85daca52309369
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
The CONFIG value precompile_header_c was ignored in the VS project
generator. Add a member VcprojGenerator::pchIsCFile that is set to
true if precompile_header_c is active.
The code in modifyPCHstage had to be rearranged to separate the three
parts for stable.h, stable.cpp and other files.
Task-number: QTBUG-62821
Change-Id: I340eb165baa22cafcb64815cf223ce9a21aca558
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Merge two nested if blocks.
This reduces the diff size for a subsequent commit.
Change-Id: If60938077169fc6686329cc5c30ebc97ada013a1
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
There's no point in having it, and this will reduce the diff of a
subsequent commit.
Change-Id: I3d27d6808c585b87a44df2499f2fcea4331befbb
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Those names are a better fit as we want to support C precompiled
headers in a subsequent commit.
Change-Id: Ie3f852da945b9b2cf0e363c81f1a4b3063f27372
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
[ChangeLog][qmake] Introduced the variables
WINDOWS_TARGET_PLATFORM_VERSION and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for overriding the default values
of WindowsTargetPlatformVersion and WindowsTargetPlatformMinVersion in
Visual Studio project files.
The code to determine the default values is moved to qmake feature
files. A common/windows-desktop.conf file is introduced for variables
common to all non-UWP Windows mkspecs.
The package_manifest feature uses WINDOWS_TARGET_PLATFORM_VERSION as
default value for WINRT_MANIFEST.minVersion, and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for
WINRT_MANIFEST.maxVersionTested respectively.
Task-number: QTBUG-53654
Change-Id: I251ec7f9b804c9bc9f7d571f5b43d52b2a2d99d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Allows a qt build to be configured to target arm64 desktop apps cross
platform and build them with nmake.
Change-Id: I99fed12047b45a504a1644201bcc19b18c69f3e6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The assert still happens on MSVC 2015 64 bit when running
qmake -tp vc -r.
This reverts commit f4169a633b.
Fixes: QTBUG-71228
Change-Id: I05bd3e0677414edb970f07e0555cdc95ce32f592
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
lld for coff/mingw doesn't support linker scripts, which qmake used
for passing larger numbers of input file names to the linker.
Instead of using a fullblown linker script for this, just use a plain
response file, which both lld and binutils ld support.
Change-Id: I3aace7902fa6ca861a0a9fe67feaa236e7ea417b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Remove the DefaultCharIsUnsigned member and XML property because the
MSVC project file no longer has a specific XML tag for that setting;
instead, the /J option should go directly into the AdditionalOptions
tag.
Task-number: QTBUG-69611
Change-Id: I8f386427b7384ae09553f66193a2c9ea2b98dbc8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The fix was for MSVC2010 which is now no longer supported
and causes a warning:
msvc_vcproj.cpp(217,12): warning: unknown pragma ignored [-Wunknown-pragmas]
#pragma optimize( "g", off )
by clang-cl.
This reverts commit 9f54846d95.
Task-number: QTBUG-63512
Change-Id: I395b964d09ac04a7dc852e43d7d95669948eea52
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@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>
For single config mode (no debug_and_release) extra compilers wouldn't
get added to the vcxproj file.
Single config mode creates a temporary project, and that was incomplete.
Multi config mode, on the other hand, directly operates on the "real
data" and wasn't affected by this problem.
Task-number: QTBUG-69769
Change-Id: I9cd942e43d80adbeac9a3c8fbe1a5766bc9645a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A switch statement using enumeration type midlErrorCheckOption as
condition had an enumeration value from type midlStructMemberAlignOption
as a case label. This had only coincidentally the intended effect, since
the intended value (midlErrorCheckOption::midlEnableCustom) and the
actually used one
(midlStructMemberAlignOption::midlStructMemberAlignOption) have both
the value 0.
Change-Id: I73b337f23e733a1a6fb80517e29365e01838238a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Generated C++ source files with extensions other than .cpp would not get
compiled, because the code ignored all other C++ source extensions like
.cc and .cxx.
Fix this by respecting the value of QMAKE_EXT_CPP and QMAKE_EXT_C.
Task-number: QTBUG-69770
Change-Id: I097dfef6920e353a351c97891cdbfdc9a859815f
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We now treat -o foo/bar/baz as a request to generate the output in the
foo/bar directory with baz as the output name, or if foo/bar/baz is already
a directory, in the foo/bar/baz directory with the default output name.
We take care to handle generator specific directory structures, so
that the project directory does not get merged into OUT_PWD. This is
done in runQmake(), before parsing the project file, so that OUT_PWD
will be correct during project parsing. The individual generators are
then passed the filename relative to the final output directory.
Each generator now also makes sure to add the right project suffix
to the output file, so -o foo will result in foo.pro or foo.vcproj,
instead of just foo.
Task-number: QTBUG-44408
Change-Id: I26990cec0c0458bee2b88dbb86322617a85f54b5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Makes it a bit more clear why all the Xcode settings were lost.
Task-number: QTBUG-45113
Change-Id: I3b19edb02a24673f56e77d3a1fb7cc76584c73fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
this allows for dynamic generation of the dependencies.
Task-number: QTBUG-61267
Change-Id: If5b8aed6b9e4bde189cc3ba6a5f13dcf8def3a1e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The Xcode project name may be affected by e.g. the -o argument to qmake,
so we can't assume it's based on the target.
Change-Id: Ibb9f4265017ffcfe26bd8734758dcb30237c704f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
under windows, libraries can have a numeric suffix derived from VERSION,
and (under MinGW) a unix-like "lib" prefix - neither of which .prl files
have. therefore, we had to make the back-mapping from the library to the
.prl file reverse-engineer the original TARGET's name. we verify whether
we actually got the right file by comparing the target specified inside
the .prl file with what we started from.
this fixes linking of transitive deps of static deps.
the alternative of changing the .prl naming pattern to avoid the
back-mapping was discarded, as a) it would be backwards incompatible and
b) it would break project-internal -lfoo references to versioned libs.
Change-Id: Ia9b899fe6a5700fee528bd1dacf130caf083cdd6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
if the file name contained no dot, but the path did, we'd chop up the
path in a final (doomed) attempt at locating a .prl file.
Change-Id: Iad72428d8523f2ea7e543faa58225fba4ffa358b
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>
move the logic for trying different extensions to
MakefileGenerator::processPrlFile(), which is the only user of that
functionality. that makes findLib() rather trivial and a bit of a
misnomer, so rename it to checkLib().
Change-Id: If9738cc17367452853ab8d3866fa36b5d4b57213
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
only .prl is actually supported (and we expect this to remain the case),
so just simplify the code.
Change-Id: Ia23f9f257bf89ca214c3deabd8a7744b155c7aa9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For some reason, the solution generator was looking for the xcodeproj
files in the source tree. It should look for them in the output tree
instead.
Task-number: QTBUG-69244
Change-Id: I7525886d614ddfdee705b27aacafc8f90a6f9d1d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
Qmake accidentally replaced all occurrences of the library name in the
build path. This would lead to problems if the (shadow) build path also
contains the library name.
Task-number: QTBUG-69279
Change-Id: If99acccc779ff0874433b193be7e7fc53625b245
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
these characters can appear in file names, but are meta characters in
dependency context. they have different semantics in make commands, so
this required some reshuffling in the windows generator (which just
treated dependencies and commands the same way).
we don't actually escape colons for nmake, because it has magic
treatment of drive letters anyway (and colons cannot appear elsewhere).
also, if a target's filename gets quoted, batch rules will blow up.
therefore, "funny" file names are really only supported as inputs -
which is just enough to make resource embedding work.
Task-number: QTBUG-22863
Task-number: QTBUG-68635
Change-Id: I473b0bf47d045298fd2ae481a29de603a3c1be30
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The macOS framework build of Qt copies headers to each
framework instead of a centralized include location.
Update the .pc file generator to match this behavior.
Add two include paths to the .pc files:
-Ipath/to/lib/foo.framework/Headers
This makes #include <FooHeader> work.
-Fpath/to/lib
This makes #include <Foo/FooHeader> work.
Task-number: QTBUG-35256
Change-Id: I013ce161c904fe6b7bbb03e33c163d32fdda0647
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
/System/Library/Frameworks is now under system integrity protection
and is not usable for 3rd-party framework installs.
/Library/Frameworks continues to be a documented framework install
locaton.
Change-Id: I26f96ed57985218452ebbf9578e08f04b4e5cfd8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The QMAKE_MANIFEST variable was ignored for VS linkers that support
the /MANIFEST:embed option.
Task-number: QTBUG-59967
Change-Id: I1cdb60ec3a7a5f117942952d4632378ff142daa5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The default value for CONFIGURATION_BUILD_DIR includes EFFECTIVE_PLATFORM_NAME,
but when overriding it in 554e44b77 we only used the CONFIGURATION variable.
This left the .app in iOS builds in Debug instead of Debug-iphoneos,
breaking deployment from within Qt Creator, which had this directory
hard-coded.
We now include EFFECTIVE_PLATFORM_NAME to restore the original
destination for the .app bundle.
Task-number: QTBUG-68705
Change-Id: If304193d3e351e19fb84d250a62ae331af6966c6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The output directory may be the same as the source directory in
the case of an in-source build, but Xcode treats the SYMROOT as
a build directory, and automatically excludes it from Time Machine
backups, which may result in not backing up sources.
Instead we map SYMROOT to an .xcode subdirectory of the output
directory, and then use CONFIGURATION_BUILD_DIR to make sure
the final build targets end up where they used to.
Task-number: QTBUG-52474
Change-Id: I3852ca9088e75ca62fca4c1217b5485175d9436f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
the dependency paths are fixified against the output directory, so we
must resolve them accordingly.
Change-Id: Id92750aad358153bd2db5daca3194c54eda58dbb
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 fixes qmake-generated project files for Visual Studio 2017 for
setups where the Windows 8.1 SDK is not installed.
Task-number: QTBUG-66265
Change-Id: I67712019f7142e40262f171eb23f9f1e6ab3a251
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This ensures that the generated XCode project can correctly find any
files that are referenced via a path containing "..".
Task-number: QTBUG-35131
Change-Id: I049bc2279b4c515a82acd61142d25b8c240e8f6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removed the '!' from two comments because the functions being
documented are static functions declared and defined in the
.cpp file. They are not public.
Change-Id: Ie3b2c32c64102634b6b2a4c438da191536a426d6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
MSVC requires that the C PCH file is compiled (as an object) and linked if
any C file is found, and the same for C++.
Most qmake projects are C++.
If a C++ project has a precompiled header, it is typically of C++ type, and
cannot be compiled as C (for example, it contains or includes classes).
Since there is no easy way to conditionally build the C PCH file only if C
files are found in the project (as done for g++), we need a setting that is
disabled by default.
This amends 30331afda1.
[ChangeLog][Tools][qmake] Introduced precompile_header_c CONFIG option for
MSVC to enable precompiled header for C sources.
Task-number: QTBUG-65103
Change-Id: Id9688a35ee7d9b5e4f5a846b81986cb674bc5f4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
