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>
QFile/QFileInfo::readLink() functions are obsolete but were not marked
as deprecated.
Explicit mark them as deprecated so they can be removed with Qt6.
Change-Id: I52424dc5441e1f5b01015713df990bbec5186caa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@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>
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>
'=' 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>
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>
Also clean up QTextCodec usage in qmake build and some includes
of qtextcodec.h.
Change-Id: I0475b82690024054add4e85a8724c8ea3adcf62a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This allows others to link to QtDBus and the other libraries/tools using
doxygen.
Fixes: QTBUG-60933
Change-Id: I026895a432a328f224c40cf231ad12d109dc648f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Martin Smith <martin.smith@qt.io>
The correct name is c++1z. Anyhow, this is easy enough to get wrong,
so make sure CONFIG += c++17 works as well.
Task-number: QTBUG-67527
Change-Id: Iea26b18824b38b1b5170f85987cf5c750b8e10ab
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
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>
turns out that flushing the ids together with the ProFile cache was an
abysmal idea, as the latter expires after a few seconds after loading
the project, while references to the ProFiles (and thus the underlying
file ids) are kept for as long as the project stays loaded. the early
flush would cause re-use of the file ids, which would wreak all kinds of
havoc when re-loading projects.
but just ref-counting the vfs class is insufficient as well, as then the
ProFile cache (which expires after a timeout) could outlive all VFS
instances and thus refer to ids which were discarded and later re-used.
so we ref-count, and additionally let the cache instance hold a
reference to the vfs class.
this is sync-up with qt creator; no actual effect on qmake itself.
amends 190aa94be.
Change-Id: Idd4478ffc1c2405b3b83df32fba45b1f687f6a18
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
(cherry picked from qtcreator/d03fb350672d311dccc06f0bcb4da744a3c99745)
(cherry picked from qtcreator/1ddfb443b686ef04cc0e28363308ce70d01f0d73)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
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>
qt creator's clang code model is a bit more picky than the old one, so
we need a project that approximately works.
while we're at it, inline qmake.pri, add some missing files, and
beautify the source lists.
Change-Id: I87ca1db2ee3e55ea08e4c23f7913e882ab44fd21
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Some distributions do not define MINGW_HAS_SECURE_API globally,
resulting in methods like wgetenv_s not being declared in the
headers.
This is probably to keep compatibility with Windows XP. Anyhow,
we don't support Windows XP anymore, so we can safely add the
define.
Note that this is not necessary for the mingw-builds distro,
which is the only one we test and support. Anyhow, I don't
see any risk in adding these for other distributions.
Diff was provided by Philippe Dunski in the bug report.
Task-number: QTBUG-67443
Change-Id: I3a64b11541fe95e527ed44bbf8ad94469d457d3d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
CONFIG+=lrelease enables that all .ts files in
TRANSLATIONS or EXTRA_TRANSLATIONS are compiled by
lrelease.
EXTRA_TRANSLATIONS is a new variable that is only
processed by lrelease, but not lupdate - this
is useful for translation files that are supposed to
be empty, because they match the language of the
original translation sources.
If embed_translations is also set, the generated .qm
files will be made available through the Qt resource
system under :/i18n/. Alternatively, the user can
specify an installation target by setting
QM_FILES_INSTALL_PATH.
Note that relative paths in TRANSLATIONS are not taken
into account. That is,
TRANSLATIONS = component1/de.ts component2/de.ts
will cause a conflict.
[ChangeLog][qmake] New CONFIG options lrelease and
embed_translations were added. CONFIG+=lrelease does
run lrelease on translation files listed in TRANSLATIONS
and EXTRA_TRANSLATIONS. CONFIG+=embed_translations does
include the generated .qm files as resources under
:/i18n/.
Change-Id: I94db5b8431d07b24f59b2c332ede91450f9c0c58
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
It's 160ish lines and adequately isolated. Still, it *might* be
contributing to compilers being slow (unlikely though that seems) so
seemed worth tidying up anyway.
Task-number: QTQAINFRA-2117
Change-Id: I9e55e677552c273fdf3480ccefc229fd6fd2b66a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
This reverts the following commits:
d12d2949d126c3bec09b49b08f96e8
We can't easily predict all code paths for QDesigner
with such a microoptimization. We also don't want
to generate three different string constructions
depending on some sophisticated heuristics.
[ChangeLog][uic] The -no-stringliteral option is now deprecated and
UIC will not generate QStringLiteral anymore.
Task-number: QTBUG-65251
Task-number: QTBUG-51602
Change-Id: I34a5a1934a8df19c5c84ac2ba8e5168ce5665037
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>
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>
in principle, it would be good to be able to read libtool .la files as
an alternative to our "proprietary" .prl files. however, this code was
disabled 15 years ago, three months after being written and never
released, and apparently no-one was missing it.
Change-Id: Ib8b4b4017b6a611f78af4e357ebce4006567e6ab
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this code operates way below the level integrating with a package
manager makes sense. consequently, remove the "TODO item".
support at a higher level is actually implemented anyway.
Change-Id: I8e1e43911dd40aa7585e49c1ad1e37b999779308
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>
The compiler was generating some vectorized code for qresource.cpp but
it wasn't very efficient. So improve upon it and make use in other
places where we read UTF-16BE strings.
[ChangeLog][QtCore] Added an overload of q{To,From}{Big,Little}Endian
that operates on a memory region.
Change-Id: I6a540578e810472bb455fffd1531fa2f1d724dfc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
make sure the access is properly scoped and does not recurse.
Change-Id: Iaa345cd2771811281b9ed6f634c70235a78c3c33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
at the time this patch was conceived, it was meant as an exercise in
getting rid of usages of ProString::toQString(m_tmp). however, this was
meanwhile superseded by use of toQStringView().
but the change itself should have been done a long time ago already, and
there is no harm in going through with it.
on the way, this also unifies and fixes some of the error messages.
Change-Id: I337aff994c508df783df4794c3fa0762d83a691b
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
... and make it explicit where we can't do that for semantical or
backwards compat reasons.
most urgently, this fixes an assertion failure when $QMAKEFEATURES
contains empty paths (e.g., due to a trailing semicolon).
notable observation: QByteArray::split() has no argument for the split
behavior (it always keeps empty parts).
Task-number: QTBUG-47325
Change-Id: I72d4b2e154a2ed1802cfa98fb4a5211a68e43231
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583e
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>
sync-up with qt-creator; no effect on qmake.
Change-Id: I7555de5c72a9250b31e20fc60e39680d19882fcb
(cherry picked from qtcreator/2cb7c81e620d224d386860a637dc889acb15435e)
(cherry picked from qtcreator/89868ee2b9093ecf40602ae302b991d6a60014b0)
(cherry picked from qtcreator/03e699ce2985eedcd33d247aa47d04b14bc4bc04)
(cherry picked from qtcreator/61419e7bf0f3bff6dcf63876b05b72c56e60c2a8)
(cherry picked from qtcreator/19eaf87ef95a510351557119a955223a4aeea7b3)
(cherry picked from qtcreator/3080bda0661989e88dfa62101b4c3f5d5e6754a1)
(cherry picked from qtcreator/99714239b616e628ff4e0afe3db7eb7511ccf569)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
sync-up with qt-creator; no effect on qmake.
Change-Id: I926bc97fe6fa510ac5a8fe77b64014333a69bd04
(cherry picked from qtcreator/8a69c254757eab7852443b5e4bd5eafb68908d3d)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
sync-up with qt-creator; no effect on qmake.
Change-Id: I34b42bd19e0de973deb2291e91f306d1ca7c630e
(cherry picked from qtcreator/15148d8e4454ff3277131ea52a4204c5fa0b7ab0)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
sync-up with qt-creator; no effect on qmake.
comment on cherry-pick: this is actually a lot more than a cherry-pick,
because the dual VFS needs to deal with the file ids which were
concurrently introduced on the qmake side.
Change-Id: I2c1eb16c97526fa275a1c6a2eae9266d385859ac
(cherry picked from qtcreator/424639ecac9d2e404d2bfaff7f46b45ed98664b8)
(cherry picked from qtcreator/a8010b0fff47d903d4a1f80e3adb1a2ef41beb33)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
it now does not see anything except regular files and directories any
more. that's not expected to be a problem, given the function's scope.
Change-Id: I53063ad8cacb3afe5cc1baf6d6d5feba3465e74f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
(cherry picked from qtcreator/cf82f210804151452fce3cddb3cb2793dab976eb)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
when the QFile object is already constructed, querying whether the file
exists is actually cheap, so do it right away instead of later on
demand. that makes the calling code a bit cleaner.
fwiw, that we need to explicitly query the file's existence at all is a
result of QFile's completely useless error "codes" (which merely say
which function failed, as if the caller would not know).
Change-Id: Ifec39d05b1713d8128046f679287e510f10e45dc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
(cherry picked from qtcreator/5ba32e3484ead2e35cc7732dcd59a97e7459dbfd)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
just a sync-up from lupdate; no effect on qmake itself.
alternative source: qt-creator/7e86b98836342035684cc1c1aa49292224faed07.
Change-Id: I5e10b44637d527799f55c578a99076eb4750f131
(cherry picked from qttools/8e7e60dbdea04c943bc6d50290db12d3fefd39f2)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Thanks to QTBUG-61373, this qmake function was called with
/usr/local/5.10.1 as baseDir, which isn't absolute, leading to an
assertion failure. We could raise the error within qmake but it
proved easier to simply resolve any non-absolute baseDir using PWD,
before trying to use it as an absolute path.
Did the same for $$absolute_path(). Documented both. Adjusted the
assert that caught this to report any non-absolute path that upsets
it. Added simple tests, fixed an existing test.
Task-number: QTBUG-66156
Change-Id: Icfef2e2f5b236e071177c9beffa38d71bf404292
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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 duplicate "for the".
Function list was sorted except for sprintf; so sorted it. Also, minor
grammatical improvement.
Task-number: QTBUG-64362
Task-number: QTBUG-64363
Change-Id: Ia47c5195011a0e578e916897b3a5ddb1d78170ad
Reviewed-by: Frederik Schwarzer <schwarzerf@gmail.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This is in preparation to adding CBOR support. We don't need yet another
dir for CBOR and placing it in src/corelib/json is just wrong.
Change-Id: I9741f017961b410c910dfffd14ffb9d870340fa6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Make it clearer what the variable actually does by mentioning
that it makes its headers available for inclusion and causes
it to be linked to the binary.
Change-Id: I72821d4bceea7a92e91175ba6c5acc4c3377d7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QFileInfo.isRelative() deems any path starting with a slash to be
absolute; on MS-Win, such paths need a drive specifier (unless they're
UNC), so use IoUtils's more robust test for absolute paths.
Change-Id: I7d0872a87833cbf1cc1a6ef107941adc4c529624
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>
For Q_OS_WIN, a path is only truly absolute if it includes a drive
letter; merely starting with a slash is not enough. (We can't support
UNC paths, so don't even try: qmake runs various commands in the
source directory using CMD.exe, which doesn't support UNC as PWD.)
This requires, when resolving a path relative to a root, transcribing
the root's drive to such not-quite-absolute paths.
Changed QMakeGlobals, $$absolute_path() and $$relative_path() to now
use IoUtils::resolvePath() rather than delegating to QDir's absolute
path method, since that doesn't correctly recognize the need for a
drive letter (and qmake did run into problems with some paths, from
splitPathList and a failing test, as a result).
Moved existing ioUtils tests for handling of relative / absolute paths
out into separate functions and expanded significantly. Fixed some
existing tests to use an absolute path where one is needed; added two
tests involving driveless (but rooted) paths; and fixed the test init
to set a value for QT_HOST_DATA/src property (the lack of which lead
to an assertion failure with this fix).
Task-number: QTBUG-50839
Change-Id: I2bfc13c1bfbe1ae09997274622ea55cb3de31b43
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
These are no longer part of Qt 5 and produce documentation warnings.
Change-Id: I82242b7b03d7ece1b82e2ff75dc6673f471e2df2
Reviewed-by: Martin Smith <martin.smith@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>
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>
Since Xcode 6.3, this must be set to NO because stripping on copy is no
longer fully supported due to the potential of input binaries being code
signed. In this case Xcode will simply ignore the strip step and issue
a warning since stripping would invalidate the code signature. This
change silences that annoying warning for release builds. Also, the
setting assignment is moved from being hardcoded in the generator, to
a QMAKE_MAC_XCODE_SETTINGS value.
Change-Id: If25511edddc12b7b0407e2992d80884b7d6437dc
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This problem does not affect the Xcode generator.
Task-number: QTBUG-65477
Change-Id: I6194edc5b679edad9ae1a25e35b71e5df9bd4c95
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This was missed in 8bebded9.
Task-number: QTBUG-63637
Change-Id: I6be472430a9aa8f533def4fd6c14c8dbfe8b6f70
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
