instead of unsetting the flag later on, don't set it in the first place.
Change-Id: Id448500b02b5c3e1dc7c332cc178a84c7fd2cfdc
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the main objective was to fix the bootstrap modules in framework builds.
bootstrapped modules which "borrow" headers from "proper" modules can
specify this in a clean way now.
a side effect of this is that the bootstrap-dbus module now has its own
syncqt call.
most includepath-related setup from qt_module_pris.prf was moved to
qt_module_headers.prf.
Change-Id: Ie0d8192cfac1a8cdae0ddd0bc0cd8c3092b1e85b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It only needs stdin now, instead of stdin plus a separate file containing
a list of file names.
Change-Id: I9f3db030001e47e4a4e5ffff1425b76884cc7ca0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
now that we don't create .pc files for private modules any more, the
conditionals cannot be nested.
amends 6c5d227da, partially reverting aa20e7f9d.
Task-number: QTBUG-49763
Change-Id: I2578c83e0c767b6533abdb26bf4e8bcc8c416ef1
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
judging by the history, this was only ever a workaround for poor rpath
handling. we're supposed to be over that.
Change-Id: I85601493a05a76ead999e707a2d2e9a430610981
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Recent versions of Qt have apparently added sufficient numbers of
headers that the command lines used to spawn a custom header-
parsing tool, started overflowing Windows' maximum command-line
length.
This change restructures the mechanism to use a GCC-style command-
line arguments file rather than passing filenames all directly
in the argv[] vector.
Although QNX is the usual ELF target whose cross-build is supported
on Windows, the mechanics introduced in this patch happen to affect
all other ELF Unix systems' builds too.
Change-Id: I5a7383cf9f2ebf9dffde8dbfdcdeca888265e085
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
no idea why it was limited to linux. the variable is already empty on
platforms which don't support it anyway. also, for plugins, it's
consistently enforced as well.
Change-Id: I117f4988a2e301ca98cdc088188d6f8c44ea0ba5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
[ChangeLog][Platform Specific Changes][OS X] Configure with -no-rpath
will now yield Qt dynamic libraries and frameworks with an absolute
install name (based in -libdir).
OS X package managers like Homebrew install Qt in a fixed location. This
change simplifies deployment for such package managers and is consistent
with the default expectation on Apple platforms for libraries with a
fixed location to also have absolute install names.
While a relocatable installation (the default) also works in this
scenario, it requires all software that depends on Qt to be aware of
this and to embed a suitable RPATH into application binaries (which is
not automatic for non-qmake builds). This might not be true for some
select fallback search locations, but as package managers on OS X tend
not to use those, embedding an RPATH becomes practically mandatory. In a
default Homebrew installation, Qt is configured such that the frameworks
end up in /usr/local/Cellar/qt5/<version>/lib and that will be later
symlinked to /usr/local/opt/qt5/lib, both of which are not searched by
the dynamic linker by default.
Task-number: QTBUG-48958
Change-Id: I4395df98771e06a2ce8a293d11dc755bdc50757f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
qt_framework and {app,lib}_bundle imply darwin, so there is no point in
testing for it.
Change-Id: I9fe48c26c8e271a5575b17e92df8674d3c3a3204
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
CONFIG+=qt_framework is actually put into qconfig.pri, so it's always
set in framework builds. things (sometimes) worked only by virtue of the
qt_framework checks being in "else" branches of "static" checks. use
lib_bundle instead, which triggers the actual framework build anyway.
amends b72d1db44.
Change-Id: Ib725c43476d9fb38bad940ce09905d29ff3edfa3
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
frameworks are currently broken anyway, and we don't create .pc files
for the private part of public modules, so creating them for entirely
private modules is just inconsistent.
Change-Id: I98da8def73d72ac69b9b246687dce6b1fd150f61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
the check whether a module depends on itself should be done by the code
which *builds* modules, not which *uses* them.
the check whether a plugin tries to use itself seems kinda pointless in
the first place, so just remove it.
Change-Id: I89b357dae7d7979d131b6824f197e7088047272f
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
there is nothing to link with it anyway.
Change-Id: I2e942d24bb39855b3682f3e8d85cb6abca75cb61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
instead of building host tools always in debug mode, follow the overall
build type, and provide an option to override it.
this supersedes the pre-existing -optimized-qmake option.
however, that option never existed in the windows configure, and this
legacy continues as far as qmake is concerned (msvc builds of qmake are
always somewhat optimized, but not mingw builds).
Change-Id: I42e7ef1a481840699a8dffff13fec2626af19cc6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Somehow qmake doesn't add the correct rules for the Android makefiles,
so the build fails when cross-compiling from Windows. The reason for
that is unknown (could be related to that "qt_android_deps" config, but
that isn't used anywhere in qmake or the buildsystem).
This isn't likely to be a problem, since there are no global installs of
Qt on Android.
Change-Id: I1d0f78915b5942aab07cffff140f95ce32324030
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
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>
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>
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>
Defaulting to absolute_library_soname on configure -rpath is no longer
necessary as now we support @rpath install name ids on OS X and iOS.
This also sets QMAKE_SONAME_PREFIX to @rpath for Qt modules when built
with rpath configuration.
This makes Qt libraries relocatable on OS X. Qt SDK is not yet
relocatable though, because plugin locations (including cocoa plugin)
are still resolved using absolute path (see QTBUG-14150). Also, there
are several absolute paths hardcoded in qmake mkspecs pri files.
Task-number: QTBUG-31814
Change-Id: I36b9384cd69ac609608acbe2b3d5e0512317e0d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
there is no need to make exceptions for install targets now, so instead
of abusing qt_no_install_library, introduce a new header_module flag.
Change-Id: I4ad7e301d1b60938b17e1dea732b1dbe3ff88a1a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
automatically set TEMPLATE=aux if qt_no_install_library is set.
Change-Id: Iccceda468da762b181fdd5c8e511bf6ed19af599
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
just like in qt_plugin.prf, the DESTDIR setting is actually fixed per
module type.
Change-Id: I5837b5884699f0d50e4067733af8aacbab93bc42
Reviewed-by: Stephen Kelly <ske@ableton.com>
Test each include file directly, instead of doing a large #include. This
verifies that each header is compilable on its own. One big advantage of
doing it via a special compiler in qmake is that we skip pre-compiled
headers, which has hidden build errors in the past.
This solution is implemented by making syncqt produce a second list of
headers. This list is the same as the list of headers in the source
code to be installed, minus the headers that declare themselves to be
unclean, via the pragma:
#pragma qt_sync_skip_header_check
This mechanism is applied only for public libraries (skipping
QtPlatformSupport, an internal_module).
This test is enabled only for -developer-builds of Qt because it
increases the compilation time.
On QtTest: the library only links to QtCore, but it has two headers that
provide inline-only functionality by including QtGui and QtWidgets
headers (namely, qtest_gui.h and qtest_widget.h). If those two modules
aren't getting compiled due to -no-gui or -no-widgets to configure, we
need to remove the respective headers from the list of headers to be
checked. If they are being built, then we need to make QtTest's build
wait for the headers to be generated and that happens when qmake is
first run inside the src/gui and src/widgets directories.
Change-Id: I57d64bd697a92367c8464c073a42e4d142a9a15f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the function is used in our examples and code generated by qt-creator,
so the qt5-specific magic behavior is inappropriate. create a separate
function instead.
Task-number: QTBUG-44595
Change-Id: I4d72cc1e5cbfc274b3210520baa213f4c5479ca9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
pkg-config .pc files use the raw target paths (and pkg-config patches up
-I and -L flags on the fly), so these files were actually already fine.
libtool .la files use the magic prefix = to denote the sysroot.
this works only with libtool 2.4+ (sept 2010).
qmake .prl files have no built-in sysrootification magic, but as they are
read by qmake, it's possible to put property references into them. this
makes them relocatable, both inside and outside sysroots.
Change-Id: I97236ac81e7aba4e4771d14a44cbf59144cc2d3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This sets the prefix for frameworks to "org.qt-project".
Applications keep using the default Xcode preferences
prefix.
Task-number: QTBUG-32896
Change-Id: I67384f643888f2de3dd8e36b9bce0f04ca4e16dd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The change was made too late in the 5.4.0 release
cycle, and broke the Qt build and deployment in
several areas:
- macdeployqt
- OS X 10.7 builds
- shadow builds
This reverts commit c0a54efc40.
Change-Id: I1c1ad4901228f5516352ccdfa963e8ea2b5013b6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Defaulting to absolute_library_soname on configure -rpath is no longer
necessary as now we support @rpath install name ids on OS X and iOS.
This also sets QMAKE_SONAME_PREFIX to @rpath for Qt modules when built with
rpath configuration.
This makes Qt libraries relocatable on OS X. Qt SDK is not yet relocatable
though, because plugin location (including cocoa plugin) is still resolved
using absolute path (see QTBUG-14150), also there are several absolute paths
hardcoded in qmake mkspecs pri files.
Task-number: QTBUG-31814
Change-Id: Ie9dffefcd2a946c1580293d433621c1adb7e06c4
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
with qmake now de-duplicating the paths properly, we should version
these QMAKE_BUNDLE_DATA entries as well, so we don't depend on the
symlinking of the regular headers being done first.
Change-Id: Idaa2ccc1ba9b5684b0c8d84f7f760735f54432e1
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
This follows the discussion at:
http://lists.qt-project.org/pipermail/development/2014-June/017225.html
Qt WebEngine will have a version of 1.0 when released with Qt 5.4.
The library name is currently libQt1WebEngine.so.1.0.0 but it should
rather be libQt5WebEngine.so.1.0.0 to represent Qt's major version
releases as a whole and not the major version of the module. This
prefix essentially expresses the module's dynamic linking
compatibility with other Qt modules.
This only makes sense if each major module release will be compatible
with a single Qt major version only.
All published modules currently already have 5 as their major version,
except qtenginio which doesn't use a Qt prefix, so this change has no
effect except for qtwebengine.
Task-number: QTBUG-30910
Change-Id: I894e7a367624c7fc263cf08104173a82eafd1439
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Move it from bootstrap.pro into qt_module.prf so it will apply to any
other bootstrapped libraries, like libQmlDevTools.
Variable called "SPLIT_SECTIONS" because -fdata-sections could be added
in the future, if it proves to be a benefit.
Change-Id: I3fbb004f111620a84e58e9112e9bce3afd95631e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
neither .prl nor .la files even contain include paths.
in .pc files, we assign the final path to start with, so there is
nothing to replace, either.
Change-Id: I919dfa01e0a1d0ef8ef1220174de1d33c66cedf9
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Added a define to suppress MSVC warning “C4996:
This function or variable may be unsafe.”
If the code is really "unsafe" then it is unsafe on
other platforms as well; so fixing these warnings just
for MSVC builds, would clutter the code and wouldn't help
in fixing issues that might exist on other platforms.
Using the same functions across all supported platforms
keeps the code clean and helps in writing code that is
safe across all platforms.
Change-Id: I470072eda4f8174bb911567ef3f061a3582ba449
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 773dd01 introduced a general mingw platform scope, which
is cleaner and more flexible than matching the spec name.
Change-Id: Ie3a9cb791a83f7c8a51bc4e23069190c452ab521
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
...unless the user passed the -no-sse2 option to the compiler.
[ChangeLog][Important Behavior Changes] Qt now automatically generates
code for processors supporting SSE2 on i386 platforms. To disable
this, pass the -no-sse2 option during Qt configuration. Since this
feature has been present on CPUs for 10 years and since Qt no longer
checks for runtime support for SSE2, we strongly encourage users to
leave the default setting on for best performance.
- For Linux distributions that must retain support for CPUs without
SSE2, we recommend doing two builds of Qt and installing the
SSE2-enabled libraries in the LIBDIR/sse2 directory. Tools,
plugins, and examples are not affected.
- See discussion on the Qt development mailing list:
http://lists.qt-project.org/pipermail/development/2013-November/014085.html
Change-Id: I7f9b1f58a9f66b6e5fe295bac15f87d34343695e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
it's bogus in the first place that the meta files contain windows paths,
but straightening that out is a prohibitive effort. so instead generate
additional s/// commands which take care of these paths.
fwiw, the generated s///i command is a gnu extension. but as we are
doing this on windows only where we are using our built-in sed command
anyway, this should be fine.
Task-number: QTBUG-33794
Change-Id: I46fcc598db12816ee56b5371ab184f6277eb3a22
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
