This way, it's possible to tell which applications and libraries depend
on the Qt private API and of which Qt library. Linux distributions can
use this information to decide which applications need to be recompiled
every time Qt itself is rebuilt.
This is done by scanning all class and struct definitions in the private
headers (we've already got the list from syncqt). I opted to add a new
script instead of modifying syncqt because then this can run in parallel
with the rest of the compilation, as opposed to during qmake
time. Another advantage is that it catches modifications to the headers
in between qmake executions.
Since this is already Unix specific, it should be no problem to use Perl.
This solution is limited to use of non-inline symbols of classes
declared in private headers. It will not catch free variables (such as
qsimd_p.h's qt_cpu_features), use of inlined functions or just plain use
of a class/struct for accessing its data members. However, this is
already better than nothing and should help Linux distributions quite a
lot. And there's no way to catch the latter issue anyway.
Change-Id: I049a653beeb5454c9539ffff13e3fff36400ebbd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
The only reason I had used them in the first place was because C
preprocessor macros cannot call themselves recursively. But the magic
was too magic and caused issues with some builds, so let's choose the
safer option.
Anyway, this solution now works for all ELF architectures, independent
of the processor, whereas previously it was restricted to x86 and Linux/
FreeBSD. However, this does not apply to the assembly in
qversiontagging.h.
Change-Id: I42e7ef1a481840699a8dffff1404f032fc5cacb8
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
If that section is there but empty, the manifest cannot be loaded using
the App Manifest Designer in Visual Studio.
Task-number: QTBUG-48648
Change-Id: I529eb2f2a690bececcf5c385b8f96e84ece363d6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
[ChangeLog][Important Behavior Changes] qmake now enables C++11 support
by default if the compiler is known to support it (unless the compiler
defaults to C++14 or a later edition). To disable this, add to your .pro
file: CONFIG -= c++11. Note that Qt 5.7 will require C++11 support, so
it is a good idea to ensure your code works with that compiler
setting. (Note: it is not possible to disable C++11 support with
Microsoft Visual Studio)
Change-Id: Ib056b47dde3341ef9a52ffff13ef13ee2cf888eb
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
src/tools/bootstrap was already compiled with QT_USE_STRINGBUILDER,
by way of load(qt_module), but the actual apps weren't.
Some apps become smaller, some larger; all (presumably) faster.
Change-Id: Idc8662e62ec14b27e730de9842bec295a1b5566e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
these were necessary to suppress the appending of the qt major version
to the library name when reading .prl files. this has outlived its
usefulness, as the .prl files now contain the full library name.
additionally, the overrides would break the use of qt if the .prl files
were not shipped, as zero lost its special meaning as "none".
Change-Id: I9f028c17fc0428cb546a4a26ee209febff32da5e
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>
This is a leftover from the unsupported Windows Phone 8.0 mkspec.
Change-Id: Ibcf11e131a3cb098960410dbd683eb5950b0c5ad
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
When cleaning in Visual Studio then it will remove all instances of tmp
files which meant it would remove the mocinclude.tmp as well incorrectly.
Therefore the extension of the mocinclude file needs to be changed to .opt
so that it is left untouched by Visual Studio.
Change-Id: Iebc055f33f9dc87a4fa42ae87b253f6739903e8f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
These variables were defined but never used in the respective qmake
features. Utilizing them allows more control over the output file name.
Change-Id: I5ba96c5cd330b18dc060f563186992fe3bd27b49
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
I've tested with Clang 3.7 and ICC 16 on Linux, XCode 6.4 on OS X for OS
X (not iOS).
Change-Id: Ib306f8f647014b399b87ffff13f1f4291d801a20
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is no particular reason to have them in qt_functions.prf any more,
while the separation made the code harder to follow.
Change-Id: Ie44c9784358f382f7bc863b421ff5b440211d66f
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
there is no particular reason to have it in qt_functions.prf.
Change-Id: I88ed1ea937a9a88a4625a6de7bcd3a29957560da
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the addition of qt's rpath belongs into qt.prf - even on mac.
so consolidate the two implementations.
as a nice "side effect", we get relative rpaths also on linux.
another "side effect" is that we don't unnecessarily add the qt rpath to
qt modules also on linux.
the qt rpath addition mechanism should not be responsible for setting
the policy who gets a relative rpath, so move the logic to higher-level
callers.
Change-Id: I52e8fe2e8279e7b1ac25fae758867a5cb1cafcf8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the rpath applies only to the installed on-device location and is
consequently always the same for all modules, so there is no point in
indirections.
Change-Id: Ia0590552aa317d799a2d3879fd0c0768344b9645
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this variable is not referenced anywhere else.
Change-Id: Ib4d0a47a08d029f65542e752fa2a47c992e061fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the old plugin loader which test-loaded plugins (without their
dependencies) is gone, so the hack is obsolete.
Change-Id: I68077cb58174dfbcb0b5372e2574de41f48d35c9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
ppc/ppc64 and 32-bit x86 have been dead for a while.
consequently, the legacy macx-g++-64 spec was most probably not used.
which in turn meant that NATIVE_64_ARCH was never set (in particular on
windows hosts ...), which means that the android ndk host auto-detection
was effectively broken.
the arch code in mac/default_post.prf was also never triggered, so nuke
it as well.
Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The use of ccache leads to QMAKE_CXX definitions of the form:
QMAKE_CXX = $${CCACHE} $${CROSS_COMPILE}g++
The previous test required QMAKE_CXX to be a single valid (absolute or
QMAKE_PATH_ENV-relative) path to an existing file, which was not
compatible with definitions of QMAKE_CXX like the one above.
Fix this by using only the first value in QMAKE_CXX, which usually
points to the compiler executable, or to the ccache executable in the
above case.
Task-number: QTBUG-47951
Change-Id: Iade3136f03493593b067fb7742fb997f92377425
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Inside Visual Studio these files (INSTALLS) will end up in deployment.
They do not make sense there and might even cause clashes, which prevent
the project file from being loaded (for example when a qrc file is added
to "Resource files" and "Deployment files")
Change-Id: Ifa68c52a83b2bf3948738c7aa1cf9c56b331dc80
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This linker script is only enabled for systems with GCC or GCC-like
compilers, though technically it should work on the BSDs too (will
enable after testing). For regular modules, this declares one ELF
version "Qt_5" and places all QtCore symbols inside, then it declares
unused ELF versions "Qt_5.x" for each older minor release. For modules
declared "internal_module", all symbols are placed in version
Qt_5_PRIVATE_API.
The big advantage of an ELF version is that, when we do Qt 6, both
versions of QtCore could be loaded in memory without conflicts and all
symbols would be resolved to the correct library. No module can talk to
both at the same time, but this avoids mistakes of loading them
indirectly by plugins.
The extra Qt_5.x versions will be used in the next commit.
Change-Id: I049a653beeb5454c9539ffff13e3fe6f050fdf31
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).
Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
We need to move adding ucrt(d).lib out of the various qmake.conf as
qmake.conf is only parsed once by qmake and does not differentiate
between debug and release.
Hence use default_pre.prf which is the earliest prf to use. This one
also is being parsed multiple times and does what it is supposed to do.
This allows API certification tests for Win10 to suceed, another
sideeffect is that it is much cleaner at a single location now.
Change-Id: Id899f4bbd063a3191c8f139857abf90efa827ffc
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
So far the dependency keyword has been ignored for the new Windows 10
mkspecs. The difference to older manifest files is that there is already
a <Dependency> section and hence we embed dependencies inside this one,
as the format standard does not allow to have multiple of those.
Change-Id: I1bf25979cc28d5c153215de5bb9cd6f37e9c50aa
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
This enables to create fully functional packages from the output of
'nmake install'.
Change-Id: Ief83532cdfc4575f7c42f5bb6a3cee4c9f0ecbd3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Since libstdc++ builds on OS X and QNX 6.5 are no longer supported,
simply require <initializer_list> and std::move in order to claim C++11
support works.
The minimum OS X versions need to be fixed elsewhere.
Change-Id: Ib056b47dde3341ef9a52ffff13ef1d2ac3923f5c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
lex.prf was trying to be halfway between the standard POSIX lex
requirements and those of GNU flex. So fix it to work with both, more or
less, by noticing when lex is actually flex and using the extended GNU
options. Note that POSIX lex is untested and may still not work.
Change-Id: Ib306f8f647014b399b87ffff13f1e8e43fb68b3c
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
yacc.prf was mostly working, so this commit simply makes it slightly
better by using the -p and -b options that POSIX requires and avoid
having a common intermediate file.
Change-Id: Ib306f8f647014b399b87ffff13f1e8e74ad4db1d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Prefer -std=gnu++11 unless strict_c++11 is defined. You can enable
strict C++11/C++14 mode by using
CONFIG += strict_c++
That is enabled for Qt's own code, so we we don't accidentally use GNU
extensions in portable code.
There's no support for strict C++98 mode (that is, the -ansi option).
[ChangeLog][qmake] By default, GNU extensions are now enabled with
Clang, GCC and ICC even in C++11 and C++14 modes. To disable the GNU
extensions, add to your .pro file: CONFIG += strict_c++.
Change-Id: Ib056b47dde3341ef9a52ffff13ef14de2169bef5
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Conflicts:
src/plugins/platforms/cocoa/qcocoafiledialoghelper.h
Manually fixed src/testlib/qtestcase.cpp to return the right type.
Change-Id: Id1634dbe3d73fefe9431b9f5378846cb187624e4
Commit 3ce99adf replaced DEPLOYMENT with INSTALLS and introduced
the "install target not created" warning when running qmake on
WinRt projects.
The code path in qt.prf that was responsible for filling the
DEPLOYMENT variable was never functional in Qt5. We're turning
the code path off until this is properly fixed.
Change-Id: If836ef648f9fb601b7597d39e3d00665d4cf01b0
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There is no test for gold linker and new dtags support for the host build
(only for the target compiler/build) which leads to trouble in some cross
compiling environments (see [1] for details).
So disable gold linker/new dtags support unconditionally for host builds.
[1] http://lists.busybox.net/pipermail/buildroot/2015-May/128303.html
Task-number: QTBUG-46125
Change-Id: Ic62828704dcce461487d63860705158cce3e4af8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
On Windows, we set VERSION for QML plugins, because this embeds a
VERSIONINFO resource into the DLL that can be inspected by the user.
Change-Id: Ifb42efed6ceee05d05f61a271e028776cac6a3a2
Task-number: QTBUG-46473
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
