There is no test for c++ standard support for the host build
(only for the target compiler/build) which leads to trouble
in some cross compiling environments (old host compiler, new
cross compiler):
g++: error: unrecognized command line option ‘-std=c++1z’
So disable c++ standard compiler flags unconditionally for host builds.
Task-number: QTBUG-51644
Change-Id: Ifb3042e125fe199a7e081740d1171d26ccacf0c5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
[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>
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>
this allows LD_LIBRARY_PATH to take precedence over the hard-coded
rpath, which is the only sane thing to do (which is also why i'm not
adding an option to disable it).
this behavior is consistent with non-linux systems.
the windows version has no auto-detection, just like for gold linker
usage.
Task-number: QTBUG-3069
Change-Id: Ief9ba032291c898d75d76ecc740390954382a804
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
This patch adds the feature use_gold_linker to use the gold linker that
has been part of of GNU binutils since 2008. Gold links C++ libraries
much faster and use less memory.
The feature is autodetected when building Qt on Linux, but can be disabled
in configure. On MingW builds it is default off but can be enabled for
cross builds.
Change-Id: Icdd6ba2e706b2c791bcf44b6e718c2b7a5eb2218
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
"system" refers to the system's native shell, which is what qmake's
system() invokes, and whose convention by far most commands invoked from
a makefile will need.
"shell" refers to the shell invoked by make, which diverges from the
system shell only when qmake/mingw32-make is called from an msys shell.
its conventions need to be used for anything the shell itself does
(e.g., assembling env variables, but also command line argument
unquoting) and the commands the mkspec sets according to the shell
(e.g., QMAKE_MOVE).
Change-Id: I0000aa9417c199cf8a810619d31ded24bb0675f9
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This patch adds a new config option to qmake to enable full optimization
where it makes sense. This currently is supported on all gcc like
compilers by exchanging -O2 for -O3.
In qtbase it is used to enable full optimizations on qtcore and qtgui
and in a later patch can be used to replace similar existing logic in
QtWebKit's WTF and JavaScriptCore modules.
This fixes a performance regression from gcc 4.7 to 4.8 in the software
renderer.
An aliasing error in qregion.cpp which was exposed by more aggresive
optimization has been solved as well.
Change-Id: Ic2c6c41b79cb3846212b40e7bcc11ff492beb27f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
As we add more classes with RValue ref qualified methods we will need
the same _compat trick and no-pch support as QString.
This patch moves the extra compiler to precompile_header.prf which is
automatically included when pch is used.
Change-Id: I422a355fd11f499ce0648a90b0385f2a6f699fcb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
that means further detaching the generation and installation of debug
info from the thing calling itself A Debug Build.
Task-number: QTBUG-32412
Change-Id: I4d79d1ae4806c8e4a2d6a7ccd030fb88385dd7d4
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
We used to compute the default exclusive build directory, eg 'debug', at
configure time, and then set OBJECTS_DIR, MOC_DIR, etc to include this
hard-coded default exclusive build directory. We then had to run a post-
process step where we replaced the 'debug' part with the current actual
exclusive build pass, eg 'release', resulting in long-standing bugs such
as QTBUG-491 where we end up replacing parts of the build output dirs
that were not part of the original exclusive build directory.
We now set the OBJECTS_DIR, MOC_DIR, etc defaults in configure like
before, but they do not include any exclusive-build information. The
exclusive build directory is handled as a separate step in default_post
where we adjust all entries in QMAKE_DIR_REPLACE to be exclusive
directories.
For backwards compatibility the new exclusive build behavior is only
enabled for variables named by QMAKE_DIR_REPLACE_SANE, which for Qt
itself applies globally to everything but DESTDIR, and for libs and
tools also applies to DESTDIR. The reason for leaving out DESTDIR in
the general case is because many tests and examples assume the old
behavior for DESTDIR. A side effect of including all the other
variables for Qt libs and tools is that the PCH output dir will be
uniformly set, which has been an issue on Windows in the past.
The addExclusiveBuilds function now takes two or more arguments,
each argument being the key for an exclusive build, which can be
customized eg. using $$key.{name,target,dir_affix}. Passing more
than two arguments results in three/four/etc-way exclusive builds,
eg debug/release/profile. Exclusive builds can also be combined, eg
static/shared + debug/release by making two calls to the function.
We also handle individual targets of combined exclusive builds,
eg static/shared + debug/release, meaning it is possible to run
'make debug' to build both static-debug and shared-debug.
Task-number: QTBUG-491
Change-Id: I02841dbbd065ac07d413dfb45cfcfe4c013674ac
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Shared between UNIX and Win generators, and allows prfs after
default_post to rely on sane TARGET and DESTDIR values.
This allows us to clean up the DESTDIR logic in testcase.prf,
which was completely busted. Doing the two in separate commits
is unfortunately not possible as the old testcase.prf logic
was so broken it would barf if only looked at.
Change-Id: Ibf21216195c760ee46ae679c162b207b77a9d813
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The 'silent' option to CONFIG will mangle QMAKE_CXX and friends by prepending
an @echo, which sdk.prf doesn't handle (it assumes the variables contain
names of executables, with optional arguments). Instead of teaching sdk.prf
generic command line parsing we ensure that silent.prf does its job at the
very end, when the tools have already had their paths fixed by sdk.prf.
Change-Id: I7093232e5cc37ed8106a3b838f42ad8f1a43fb86
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
all tests that happen after default_post loads resolve_config can rely
on debug vs. release, static vs. shared, and staticlib vs. dll being
properly "de-conflicted".
Change-Id: Ie0b4defcd6024bd1c25f53ba7e03621052d96492
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the current approach of having "free-flying" prf files for such a core
issue is rather insane. this was noticed early on, as evidenced by the
forcible loading of debug/release/debug_and_release in default_post.
however, things remained a mess, in particular static vs. shared.
consequently, the commit merges all related feature files. the actual
config resolution is put in a separate feature file, so it can be loaded
by resolve_target if that happens to be loaded early on.
Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead of letting *every* qmake-based project have recursive check target,
let interested projects "subscribe" to it by adding CONFIG+=testcase_targets
in a central place (.qmake.conf, which Qt itself does via qt_build_config.prf).
Change-Id: Ib13fdd2d3a1adee0c5ad02b6b176a664c583bf9d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead of letting *every* qmake-based project have recursive docs targets,
let qt modules "subscribe" to it explicitly by having load(qt_build_config)
in their .qmake.conf (which they already do).
Change-Id: I97b74591fd0c4bd5f8b08c5f550df9c7eef2f556
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
- the old docs target becomes html_docs
- a new qch_docs target is added. the .qch files end up directly in
QT_INSTALL_DOCS, wihout any subdirectories in between
- the new docs target invokes html_docs and qch_docs
- respective un-/install targets are added as well. note that the
install targets don't depend on the build targets, as it's virtually
impossible to get the dependencies right throughout the hierarchy.
Change-Id: I07a2589db8252371e77cf925c47c4e59fbd1b2ca
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
The new 'prepare_docs' CONFIG option triggers the documentation rules in
default_post to generate two extra targets: prepare_docs and generate_docs.
The prepare_docs stage runs qdoc with the -prepare option, which means qdoc
will only generate index files, and the generate_docs stage will call
qdoc with -generate, which reads the index files and generates the final
output. The regular docs target will then run the prepare_docs target
for all submodules before running the generate_docs target.
This ensures that when generating the final output, qdoc has all the
index files for all the other modules available, to be able to resolve
cross-references between the various Qt modules.
This patch needs a follow-up in qt5.git to add CONFIG+=prepare_docs, so
that the root Qt5 build will be able to hook into this new behavior.
Change-Id: I654d7f0d4d5a41d9be208e6d3a8923bf0194f9ad
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Just like 'make docs' is used to build documentation, you will now have
to run 'make install_docs' to install it.
Change-Id: I57db53160ca91618784f4e39da0a47322c070208
Task-number: QTBUG-27590
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The qmake function prepareRecursiveTarget can now be used both by the
existing logic in default_post, as well as future recursive targets that
will be needed as part of the modularization of documentation builds.
Change-Id: Ibc72c3e224cb57c9f1796de3b04fda9de663dbb4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qdocconf files can now reference $QT_INSTALL_DOCS to pick up e.g. global
includes, instead of using relative paths. Qt modules will automatically
get a doc target that builds and installs into the right place (including
supporting shadow-builds) if they set QMAKE_DOCS before loading(qt_module).
Change-Id: Ia408385199e56e3ead0afa45645a059d1a8b0d48
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
the system path separator and shell are bound to the host system
(system() will use cmd even on mingw with sh.exe in path).
the makefiles otoh may depend on what the qmakespec defines.
consequently, add $$system_path() and $$system_quote() (for use with
system() & $$system()). $$native_path() is renamed to $$shell_path() and
should be used with $$shell_quote() to produce command lines in
makefiles.
$$QMAKE_DIR_SEP needs to be applied to Option::dir_sep right after
parsing the spec, so it is available to $$shell_{path,quote}().
Change-Id: If3db4849e7f96068cf03a32348a24f3a72d6292c
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Up until now, we had a mess of different macros used for building
DLLs, for building shared libraries on Unix systems and for building
static libraries. Some of the macros were contradictory and did not
work. From now on, there shall be only:
- QT_STATIC: indicates that it's a static Qt build and the export
macros should expand to empty
- QT_SHARED: indicates that it's a shared / dynamic Qt build and the
export macros should expand to Q_DECL_EXPORT or Q_DECL_IMPORT,
depending on whether the macro corresponds to the current module
being built (the QT_BUILD_XXXX_LIB macro comes from the module's
.pro file)
QT_BOOTSTRAPPED implies QT_STATIC since the bootstrapped tools link
statically to some source code.
QT_STATIC is recorded in qconfig.h by configure when Qt is configured
for static builds. Nothing is recorded for a shared / dynamic build,
so QT_SHARED is implied if nothing is defined. This allows for the
existence of a static_and_shared build: with nothing recorded,
defining QT_STATIC before qglobal.h causes the export macros to be
that of the static form. Linking to the static libraries is out of the
scope of this change (something for the buildsystem and linker to
figure out).
From this commit on, the proper way of declaring the export macros for
a module called QtFoo is:
#ifndef QT_STATIC
# ifdef QT_BUILD_FOO_LIB
# define Q_FOO_EXPORT Q_DECL_EXPORT
# else
# define Q_FOO_EXPORT Q_DECL_IMPORT
# endif
#else
# define Q_FOO_EXPORT
#endif
The type of the Qt build is recorded in QT_CONFIG (in qconfig.pri) so
all Qt modules build by default the same type of library. The keywords
are "static" and "shared", used in both QT_CONFIG and CONFIG. The
previous keyword of "staticlib" is deprecated and should not be used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2012-April/003172.html
Change-Id: I127896607794795b681c98d08467efd8af49bcf3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is no point in adding Qt modules to SUBDIRS projects.
as QT contains core and gui by default, the operations are relatively
expensive, so skip them when they are unneeded.
Change-Id: Ibe6447ff452e403cb040fabe245d248edbda0eaa
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the check whether we are building a lib or an app (and thus have a target)
is done by quite some feature files (and generally wrongly, as they do not
account for the new aux target), so centralize it in default_post.prf.
Change-Id: I868edbc4185be8a6c23ecd4a2c126024d73cdeb4
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Normally you want to pass -installdir $$[QT_INSTALL_DOCS] to qdoc by
default. However, if you want to force the generation of URL links to
the documentation, the option cannot be specified.
By setting the QMAKE_DOCS_INSTALLDIR variable in default_pre.prf a
project may override it at will, as for example Qt Creator would do.
Change-Id: Ib31f03acf4e8050cf2dd3aa33f3a10ed027f1df7
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Only call qdoc for projects which sets the QMAKE_DOCS variable to
point to a qdocconf file.
Exclude examples/ and tests/ from the qdoc run, by adding
no_docs_target
to CONFIG for those projects.
Change-Id: Ic856c8f19db59309302d0602b3e99735609e525a
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
If subdir.CONFIG contains no_check_target, we do not recurse into
that subdir when generating the 'check' target.
This will be used to selectively disable crashing tests on Mac OS X.
Currently, all autotests are disabled on Mac OS X. The goal is to re-
enable them, but not all at once. This approach allows us to get each
change through the CI system individually.
The first step is get all tests to build, but not run, then we will
re-enable the tests for each module, possibly disabling individual
tests at the same time.
Change-Id: I69f62c238f381ae0315d414cd71d76bc88b088dd
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
TARGET_BASEPATH becomes QMAKE_RESOLVED_TARGET.
QMAKE_RESOLVED_TARGET will be reused for future implementation
of code coverage tool TestCocoon.
Creating of resolve_target.prf.
Clean unused "unset(SYMBOLFILENAME)" in default_post.prf.
Change-Id: I054efb0065fa06697b60ac60a9ddf364f2f40366
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
If the compilation of a subdir was explicitly disabled by default, then
the testing of that subdir should also be disabled by default.
Change-Id: I928e232393e89a7c27813b7a48864d4e0fb687f8
Reviewed-on: http://codereview.qt.nokia.com/2835
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Kalle Lehtonen <kalle.ju.lehtonen@nokia.com>
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
