adding shared install paths via QMAKE_LFLAGS in the spec has the tiny
side effect that they are searched _first_, which is generally a really
bad idea - they should be _last_.
for that purpose, introduce QMAKE_RPATHLINKDIR_POST, and migrate all
specs to use it.
QMAKE_RPATHDIR_POST is added for consistency, but not actually used.
Task-number: QTBUG-59457
Change-Id: Iac6cda5e9111ef8cca454a69861fe8408bb40589
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
adding shared install paths to QMAKE_{INCDIR,LIBDIR} in the spec has the
tiny side effect that they are searched _first_, which is generally a
really bad idea - they should be _last_.
for that purpose, make QMAKE_{INCDIR,LIBDIR}_POST live up to their names
(i.e., search them actually last) and migrate all affected specs to use
them.
Task-number: QTBUG-40825
Change-Id: Ie0de81c3cc49e193186d2fedd7d6c77590c8ef79
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As the directory installation command also works with files as a source
we can unify the external commands, resulting in simpler command lines.
Change-Id: I65013626eedbdb3ce1c77ed230d46edd1603b986
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Similar to the two parent commits, this patchs preserves the time stamps
of files we install as a result of recursive directory copying.
Change-Id: Id5931a467196d5cd67acfa0deffc2488af8a3669
Task-number: QTBUG-59004
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The original commit only added support for GCC and Clang, but not ICC.
Amends 73331eeb
Change-Id: Id7638cf1b538edb1008fb3aa10754c1f517a994f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Similar to the parent commit, this patch adds a unified code path in
qmake itself for installing program files while preserving their
original last modification timestamp.
Change-Id: I7b7dcfa6228c2bfd48ea6036549398bb6f90032f
Task-number: QTBUG-59004
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
On non-windows platforms, we use the "-p" parameter of install(1) to
preserve the last modification timestamps of files. On Windows the use
of copy does not preserve them. As a cross-platform solution, this patch
introduces a simple built-in install command in qmake to copy files.
Task-number: QTBUG-59004
Change-Id: I3064d29a2b8c7b009a1efbf8f00b84c079ea5417
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
prelink was not supported at all for ar.
postlink was done for most cases, but missing in one particular ar
invocation.
Task-number: QTBUG-57276
Change-Id: Ic72c42a9502c97d7111b3f3941b387024d46a27d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the arguments after '--' are by definition meant only for the top-level
project, as that's where configure is invoked from. passing them to
sub-projects just adds noise to the make output and misleads users.
note that this specifically does not support qmake -r, which will break
if the subprojects rely on the arguments being absent. this isn't a
problem, because the qt build doesn't support qmake -r anyway.
Change-Id: I7ecff6212ce3137526005fc324a4a7ae45e3345e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The actual blocker for precompiled headers is not the iOS/tvOS/watchOS
platforms, but the way qmake handled multiple-architecture builds on
Apple platforms.
This patch allows multi-arch builds to be performed while using
precompiled headers.
Since df91ef3d6c55692a0236f67b6c6b134a3bf84098 (April 2009), Clang has
had support for PCH files in the driver, which allows to use the
-include flag to automatically translate to -include-pch. We can then
take advantage of the fact that the -include option is allowed to not
be separate from its argument, which lets us take advantage of -Xarch to
specify a per-architecture precompiled header file.
This is done through some magic in the qmake Makefile generator which
"multiplexes" the PCH creation rule across multiple architectures and
replaces a series of tokens with the proper precompiled header paths
and architecture flags at usage point.
Change-Id: I76c8dc9cda7e218869c2919f023d9b04f311c6fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This fixes a bug where joined device and simulator builds would get
for example, QtCore_iphonesimulator as the CFBundleExecutable.
According to Apple:
"For frameworks, the value of this key is REQUIRED to be the same as
the framework name, minus the .framework extension."
This does not affect the ability to load a framework whose executable
name differs from the bundle name (as is the case for simulator builds),
as the application will be linked to the correct framework executable
at link time by specifying (for example) the linker flag:
-framework QtCore,_iphonesimulator
Change-Id: Ib7614670d0620e0235cd7e2606d42dd034a90c68
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
the inherited arguments may contain the '--' argument, which turns
additional arguments into configure arguments. the simplest fix for
that is injecting additional arguments at the front, not at the end.
Change-Id: I7cc00a42f0148e5ccbbeda2ad59fa8c63749f02d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Plugin bundles are not frameworks, so this fixes the case where a lib
template with plugin and lib_bundle in the CONFIG would be mistaken
for a framework bundle, which has a different filesystem layout and
handling.
Change-Id: I9ce9daf22d4e3de70bfe7bc8bb219068de0bca42
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is a prerequisite for properly constructed framework bundles.
On certain Apple platforms (iOS, tvOS, watchOS), bundles are used
in "shallow" format, meaning that the directory structures are
flattened compared to the one used in macOS bundles.
shallow_bundle allows the difference to be expressed independently
of the platform. Note that the term "shallow bundle" is used by
Apple in Xcode internals.
Change-Id: I1189c52b0ea66843c313783176c11cc2af97ad25
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
And blacklisted a few tests in tst_QUdpSocket.
Conflicts:
src/android/jar/src/org/qtproject/qt5/android/QtNative.java
src/corelib/global/qglobal.cpp
src/corelib/global/qsystemdetection.h
src/corelib/io/qfileselector.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp
tests/auto/network/socket/qudpsocket/BLACKLIST
Task-number: QTBUG-54205
Change-Id: I11dd1c90186eb1b847d45be87a26041f61d89ef6
This resolves an issue where qmake would generate a Makefile with an
install command immediately followed by a test command, with no
intermediary newline and tab to separate them.
Task-number: QTBUG-54035
Change-Id: I7f9226f25e92b49ce689d252e9c4a58b877f2972
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this introduces an ambiguity, so some char* arguments need explicit
QString construction now.
Change-Id: Ic3919a1fa9419bbb3b57dd1aa7eb95643ee59e53
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change partially reverts 1bfc7f68 about QT_HAS_BUILTIN define
and undef in src/corelib/tools/qsimd_p.h.
This change is also squashed with "Fall back to c++11 standard
compiler flag for host builds" which is done by Peter Seiderer.
Conflicts:
mkspecs/features/default_post.prf
src/3rdparty/sqlite/0001-Fixing-the-SQLite3-build-for-WEC2013-again.patch
src/3rdparty/sqlite/sqlite3.c
src/corelib/tools/qsimd_p.h
src/gui/kernel/qevent.cpp
src/gui/kernel/qwindowsysteminterface.cpp
src/gui/kernel/qwindowsysteminterface_p.h
src/plugins/bearer/blackberry/blackberry.pro
src/plugins/platforms/cocoa/qcocoasystemsettings.mm
src/plugins/platformthemes/gtk2/gtk2.pro
src/plugins/styles/bb10style/bb10style.pro
src/sql/drivers/sqlite2/qsql_sqlite2.cpp
tools/configure/configureapp.cpp
Task-number: QTBUG-51644
Done-with: Peter Seiderer <ps.report@gmx.net>
Change-Id: I6100d6ace31b2e8d41a95f0b5d5ebf8f1fd88b44
... by replacing them with C++11 range-for loops.
To avoid detaches of these mutable Qt containers,
wrap the container in qAsConst().
Change-Id: If086bea06fe26232a7bb99fad8b09fce4dc74c27
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
The functions QMakeProject::values(), QMakeMetaInfo::values()
and QHashIterator::value() all return by const-reference,
so they can be passed to range-for without further changes.
Change-Id: Ic3b39ed8ff8cd7a6f287f1aa9d61a1acd67d7aaa
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
I wrote a script to help find the files, but I reviewed the
contributions manually to be sure I wasn't claiming copyright for search
& replace, adding Q_DECL_NOTHROW or adding "We mean it" headers.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b506368fc8842
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
When building QNX on MS-Windows, make magically adds the Msys root as
prefix to variables whose values look like paths; this applies to both
environment variables and variables given values on the command-line.
When we don't actually want to install under the Msys root, this is
unwelcome "help". So (for MinGW's make) support a magic prefix of our
own, @msyshack@, that'll make a path value for INSTALL_ROOT not look
like a path to make; we can then strip it off when we come to use it.
Change-Id: I951ad3c8fe3e5cfb49e6e361d7fff779f3a9d716
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... and make use of it in qt.prf.
[ChangeLog][qmake][Unix] Added support for relative paths in
QMAKE_RPATHDIR.
Note that this technically breaks backwards compatibility, as relative
paths were previously silently resolved against $$_PRO_FILE_PWD_. This
was not documented and seems rather useless, so i'm not worried.
Change-Id: I855042a8962ab34ad4617899a5b9825af0087f8a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
at least the mingw version we use now interprets the sequence \# as a
literal hashmark, which completely defeats the previous hack.
the new hack escapes the backslash with another backslash, which appears
to work. however, make does *not* remove the additional backslash, so
the result is a bit ugly.
Change-Id: I591a2be443880b162094d04e5a5e624216b59311
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Suffix rules are the old-fashioned way of defining implicit rules for make.
We don't need them as we generate explicit rules for all sources we build.
[ChangeLog][qmake] Makefile output no longer contains implicit
suffix rules, as all sources are built using explicit rules.
Change-Id: I4ecfa5b80c8ae33aea8730836f3baf99dd4951dd
Task-number: QTBUG-30813
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources
into the same pile, passing them on to the same compiler as for C++ (CXX),
with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as
variants of the C and C++ languages separately, so that Objective-C
sources are built with CC and with CFLAGS, and Objective-C++ sources
with CXX, and CXXFLAGS.
This lets us remove a lot of duplicated flags and definitions from the
QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched
the C++ equivalent. The remaining Objective-C/C++ flags are added to
CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in
C/C++ mode. This matches Xcode, which also doesn't have a separate build
setting for Objective-C/C++ flags.
The Makefile qmake generator has been rewritten to support Objective-C/C++
fully, by not assuming that we're just iterating over the C and C++
extensions when dealing with compilation rules, precompiled headers, etc.
There's some duplicated logic in this code, as inherent by qmake's already
duplicated code paths, but this can be cleaned up when C++11 support is
mandatory and we can use lambda functions.
Task-number: QTBUG-36575
Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
first, store the library's full name in the .prl file, like we do on
unix. this is not expected to have any side effects, as QMAKE_PRL_TARGET
was entirely unused under windows so far.
then, rewrite the mingw library handling: instead of letting the linker
resolve the actual libraries, do it ourselves like we do for msvc. we
could not do that before due to the partial file names in the .prl
files: if the library didn't exist at qmake execution time, we'd have to
guess the file extension (the msvc generators never had that problem, as
they know about only one possible extension for libraries anyway).
make use of processPrlFile()'s ability to replace the reference to
the .prl file with the actual library. that way we don't need to
re-assemble the file name from pieces, which was fragile and
inefficient.
QMAKE_*_VERSION_OVERRIDE does not affect libraries coming with .prl
files any more. additionally, it is now used literally (not
numerically), and values less or equal to zero lost their special
meaning as "none" - this isn't a problem, because that's the default
anyway, and there is no need to override bogus versions from .prl files
any more.
no changelog for that, as i found no public traces of that feature
outside qtbase.
[ChangeLog][qmake][Windows] Libraries coming with .prl files can now
have non-standard file extensions and a major version of zero.
[ChangeLog][qmake][Windows][Important Behavior Changes] The .prl files
written by earlier versions of Qt cannot be used any more. This will
affect you if you depend on 3rd party libraries which come with .prl
files. Patch up QMAKE_PRL_TARGET to contain the complete file name of
the library, and replace any /LIBPATH: in QMAKE_PRL_LIBS with -L.
(the part about /LIBPATH: actually refers to the next commit.)
Change-Id: I07399341bff0609cb6db9660cbc62b141fb2ad96
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
seems pointless to tear apart the functions, on the way duplicating some
boilerplate.
Change-Id: Ide3697ca1c931e8de607ac48c21cecce4781fe13
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this feature was added with a dubious commit message a decade ago, was
undocumented, and there are no public traces of it being used.
if i had to guess what it was meant for: to be able to consistently use
-lfoo throughout a project and centrally (e.g., in .qmake.cache) choose
to use foo<bar> (bar possibly being "d") instead. however, more explicit
methods are being used instead, including in qt itself.
Change-Id: Ic3a98dc3aec59876f26909fbf9f7aba32baa05bf
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
"why not use libtool?" -- sam
"srsly dude?!" -- ossi
[ChangeLog][qmake] Support for CONFIG+=compile_libtool was removed. Use
CONFIG+=create_libtool and/or custom compilers instead.
in addition to its utter insanity and superfluousness, this feature was
apparently quite broken anyway (QTBUG-35745).
Change-Id: I8147a2953f5f065735ae3a2206cd5d33a7c1809a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this code would get enabled when *not* compiling with libtool, and would
try to use the real library in .libs/ when one tried to link the .la
file (i.e., it would reproduce libtool's functionality). that directory
structure is found only in build directories, so this code was
apparently meant to support mixed projects. that doesn't sound useful.
on top of that, the other code paths that were supposed to treat .la
files like .prl files were disabled before initial release (because
Somebody (TM) noticed that their code "doesn't behave well"). this code
here did the same thing, but at the wrong abstraction level.
as a side effect, this removes an infinite recursion problem in that
code.
Task-number: QTBUG-46910
Change-Id: If5291f5ff42c1412075c195753162c54598a250e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
there is no need to consider the "-framework foo" syntax, as we fully
control the list and insert elements exclusively as "-framework" "foo" a
few lines down.
Change-Id: I95fa8b46f53673ea3df1a67a2a44d11f7d679cc6
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the code had a dead variable assignment and no side effects.
Change-Id: I9add8f1776f23a29c103b46dc725b9f386a4495a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it appears to have been some weird attempt at back-mapping file names to
-l arguments, which has been made ineffective with the partial #if 0.
i can't even describe what it did at this point.
Change-Id: Ie31cbbe7fab8b21b039bfff5877397af07731f1b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the assumption is that if somebody bothers to actually specify a file
name, they'll most probably go all the way to specify the *correct* file
name. otherwise, they'll use -L/-l flags to specify the libs in a
cross-platform way and rely on qmake's magic.
this code was initially added for the purpose of invoking
findHighestVersion() under windows. this has been off by default for a
while now.
at some point, the code did also swap qt for qt-mt and vice versa if the
specified one was missing. this is obviously gone for a while as well.
the unix code was pretty much broken since day one: there was a regex
match on lib<stub>.* against <stub> itself, which obviously could not
have ever succeeded. consequently, the subsequent code ran into a path
that tried the file name with a trailing dot (instead of a new
extension), which never produced anything meaningful.
[ChangeLog][qmake][Important Behavior Changes] The library lookup has
been simplified. It may be necessary to be more explicit in some edge
cases now.
Change-Id: I5804943f1f7a16d38932b31675caabbda33eada7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
make sure that all specs define QMAKE_{PREFIX,EXTENSION}_{SH,STATIC}LIB,
and adjust the code to make halfways consistent use of these variables,
in particular on windows; Win32MakefileGenerator::getLibTarget() is gone
as a result, as is QMAKE_CYGWIN_SHLIB. still, tons of hardcoded "lib"
references remain in the unix generator, because no-one cares.
Change-Id: I6ccf37cc562f6584221c94fa27b2834412e4e4ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it would cause the unix generator to set TARGET_EXT, but that wasn't
used anywhere. so remove the dead code. if it ever gets re-introduced,
it will be as QMAKE_EXTENSION_EXE.
Change-Id: I44ce3e612651fd229177e37ab6c8879cd8c474b7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
rvct and armcc support are remnants from symbian, while the ti linker
support was never completed in the first place.
Change-Id: I5c9d7f0ce67de24c348cbee4af618a499fe06f16
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
there is no reason to expect the various list elements to be
space-encumbered, or to tolerate it if they were.
Change-Id: I1a2e5c8d30456b640408503334c55f9262792db5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Consider a debug_and_release build of a static library.
Set DESTDIR to different values for debug/release.
Let TARGET be the same for debug/release.
Now qmake would generate code in Unix Makefiles like this:
rm mylib.a
ar mylib.a ...objects...
rm debug/mylib.a
mv mylib.a debug/mylib.a
and for release analogous. This clashes when building in parallel.
This patch resolves this conflict by reducing the commands to:
rm debug/mylib.a
ar debug/mylib.a ...objects...
We believe that every ar implementation that's in use for Qt
is able to operate on files in subdirectories.
[ChangeLog][Important Behavior Changes][qmake][Unix] QMAKE_POST_LINK
steps of static libraries are now required to operate on $(TARGET) in
$(DESTDIR) instead of $$OUT_PWD. This matches the Windows backends.
Task-number: QTBUG-48287
Change-Id: I192f488ed74c56bc32862426d9e9d4237d9b8135
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
$ORIGIN (or $LIB) needs to be escaped to survive the trip through
make and the shell.
this shouldn't break anything, as there was simply no way to get it
right so far.
Change-Id: I86337c5994d10dae2e80dd2f858f74874b14bca7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
