Also check for c++11 support in configure.exe (which is also used by MinGW builds).
The c++11 check is therefore moved from 'unix' to 'common' directory.
Change-Id: I082848f032c2770e52e34f331b83820f395c06b6
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Yuchen Deng <loaden@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
we don't need it any more, as the makefiles are self-contained now.
Change-Id: I1a560a8331856e246e03c55ec1b1dd1a5cb112e4
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the bootstrap does not need CamelCase includes, deprecated headers and
whatnot, so just don't do it. the full thing will be run on qtbase by
qmake.
Change-Id: Idffdd4750a73574c8c32ee75d00080abfe37e03c
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
for faster bootstrapping without a full syncqt run
Change-Id: I648f0a8fb09be021590c46e8e5e15667a316c817
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it needs no special env variables any more
Change-Id: I60a7ab6eabb9280b02cd510418c0842d05fc1306
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
DEPENDPATH is hard to get right, and consequently most projects have
broken dependencies.
the easy way out is just adding everying in INCLUDEPATH to DEPENDPATH,
like we do ourselves in qt. if somebody wants to optimize, he can
opt-out.
Change-Id: I7fb56010728fd2b0d2b7d4d26386f366d414ba04
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
The -developer-build option in the configure shell script is right after
-force-debug-info, move it to the same place in the Windows version.
Change-Id: I9b944f8591011ce9987a4fb98f7d02d88160d9e8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Displaying config.summary sometimes results in an infinite loop because
the loop condition only checks that failbit and badbit are not set.
The eofbit may be set with failbit and badbit not set.
Change-Id: I209480fbf114365fd4fdf1289c988a386f9f2562
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
It did not compile because at the time qconfig.h was preprocessed,
QT_NO_ICONV was already defined, causing the #define QT_NO_ICONV to
fail. It should be guarded like most other defines in qconfig.h.
Also fix QT_CUPS=no, QT_ICONV=no, QT_GLIB=no, QT_NOTIFY=no and
QT_LARGEFILE_SUPPORT=64 the same way.
Change-Id: Ic9e0295756c35cb7c62e18eb9b63b1410e7de051
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
This reduces dramatically the command-line for compiling Qt sources.
These are private macros, only to be used by Qt's own modules, so the
compiler setting is either the same or, possibly, better. In other
words, in the worst case, when compiling a module with a better
compiler than for qtbase, such module might not enable all the
functionality it could otherwise do.
If we switch to a buildsystem that can support this properly in the
future, these macros should be removed.
Change-Id: I71f2d12ec98c9dd40eaab9de4a17446bd1066020
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
hard-coding it in unix.conf was no particularly good idea for hopefully
obvious reasons.
the windows version is so far just a stub that does what the makespecs
hard-coded - more doesn't seem worth the effort. the guys interested in
x-building may want to rectify it at some point, but it's not going to
be easy.
Change-Id: I8fedd841a8416f8c0c57018752eae9510b5d00d0
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Windows CE does not have support for GetGlyphOutline.
So addGlyphToPath will not work. QML uses it for their
distance field rendering. One option to bypass this issue
is to use freetype as rendering backend.
Change-Id: I965254344945cbdad771a5d505fb61c1cc2087df
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
qurl.cpp was removed from the Makefiles on 6ab6b0fc1c,
but I missed the .pro file. You're not supposed to use the .pro file
anyway, it's just for opening in Creator.
But if you forget to remove the qmake build step, it would get compiled.
Change-Id: Ia52ae7349e195df58f76f8d2c5f8b46adfdc7454
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
a module's project file may set MODULE_INSTALL_LIBS before loading
qt_module.prf to have an alternative RPATH linked into the users of that
module.
this is relevant only for linking against non-installed -prefix builds
of that module, as otherwise .libs from the module's pri file is used
for rpath.
Change-Id: Ib240e748cf130a71a5991dc643c368a983092ead
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Microsoft has named their new Visual Studio again
after the old naming schema.
Change-Id: Ib1b971807fa89d90b10892a2d78570058e564f3a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Under Windows it's quite possible that OpenSSL, DBUS or MySQL is
not installed into a central place. If -I and -L is
passed at configure time, it is added to all targets,
and if that path contained a conflicting header things would go
wrong.
Change-Id: Ic3338c49aa6eaa91b3abf5341e709ef604bf7aab
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
configure will now run qmake without -recursive, as on modern systems
one can get a lot more out of parallelization done by make, which qmake
cannot do.
use -fully-process to get back the old behavior. -dont-process is
unchanged.
Change-Id: I2874321a963175463ae8992f3ab2b01bc13c9922
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
i think this was a vestige from the old wince build proces
Change-Id: I13305de627c65fc1c93ba6d2383557ff5ea7a147
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
they are an unreadable and unmaintainable mess. the options are properly
documented below.
Change-Id: If2ec683fb7c3740b19798979f8a1f9cd8d84f457
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This option is important if you want to use configure's
and qmake's -sysroot (e.g. PKG_CONFIG settings, device-files),
but the toolchain (in combination with the rootfs)
is not able to handle gcc's --sysroot.
One known case is freescale's ltib setup where the toolchain
itself comes with all the essential files (e.g. crt1.o),
while the rootfs has none of those files, so gcc's
--sysroot can't be used. The rootfs on the other hand contains
all kinds of "less important" files/packages (e.g. libdbus).
For those "less important" files/packages Qt needs pkg-config
to be able to include/link properly. Therefore one needs
configures -sysroot without gcc's --sysroot.
Change-Id: Iaec9b07012f2945f3ecb3ced0ed95176721b5ecd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
msvc cannot use the same library for debug and release builds
if openssl libraries are linked statically into the network library.
Change-Id: Ic27ede2d9531b94aff4c50c1699947ce72caf286
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Without this, if you ran 'nmake qmake' or 'jom qmake' in qtbase's
top directory, it would simply tell you that 'qmake' was up to date.
After all, there is a directory called 'qmake' there.
Change-Id: I6cdb405e8106c137ecbab27923e524b924b19c84
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Detect CUPS availability automatically when cross-compiling from a Windows
host.
Change-Id: Ife9bb90732c39794a7b760ced4aaea232612fe54
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Do not build windows styles when the target platform is not Windows. This
makes a difference when cross-compiling.
Change-Id: I2184d39ed253af1069c5cdcd6a848611cff24789
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Enable auto detection for iconv when
cross-compiling from Windows hosts.
Change-Id: I699e0a31d938403f5e80e74be90df87f11f361ba
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
All auto detection tests were failing
because the default mkspec was not yet
installed during the time they were run.
Change-Id: Iad14580f38d1539d9831917e5c9c707eae4c0c90
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
In systems where no pkgconfig is available, such as QNX, we set
QT_LFLAGS_SQLITE to the default values.
Change-Id: I24edd589ce7baf2614480a91842ca756ead39463
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Tools for each module should be enabled by default.
Prior to qt_parts.prf, they have been enabled by default, but only by
accident - the value of QT_BUILD_PARTS with respect to 'tools' was
generally not respected.
Change-Id: Icd49d6128d4050ff1c865967a563e9ab88c5a3a2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this stopped the installation of mkspecs for windows ce
Change-Id: Ic57337904b88e4460f9f4110b08ecefb1a2eed8b
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
that way it is actually possible to add additional parts from the qmake
command line.
Change-Id: I42e0b58424292cebafb57538a879204d370397bb
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
this makes it unnecessary to dump qmakespec to .qmake.cache and
qmodule.pri.
Task-number: QTBUG-22700
Change-Id: I678c7ee7df2512184b9cd06d7a3be8bbd0b0da15
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this will fail now even on unix (and wouldn't have ever worked on
windows), as the full spec name is known only after reading the spec,
and qconfig.pri is read from inside the spec.
matching on the host_build flag is cleaner anyway.
Change-Id: I7da144e89ab3db0fad942d755d8cb0a0f3b85588
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Donald Carr <sirspudd@gmail.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
The SXE feature was used with Qtopia but is long gone. Clean it up.
Change-Id: I55fba97b6382300ba63e94f3a6c415227f571e37
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
refactoring and cleanup. fixes x-builds between different os families.
Conflicts:
mkspecs/features/qt.prf
Change-Id: I0205e6f07f77c9b015cf055dd87a471883949a91
qmake is needed by autoDetection()/tryCompileProject() to be able to build the
tests. This patch also add a new method - generateQConfigCpp() - which
generates qconfig.cpp, needed to build qmake.
Change-Id: Ic304a364a13a2b3c28433f2a299df222a56fed67
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
QT_NODLL is replaced by QT_STATIC, but the latter is implied if
QT_BOOTSTRAPPED is already defined. Therefore, simply remove the
QT_NODLL definitions.
Change-Id: Iac7ec0b494b7a78197c25d59547f45eaf92d7465
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.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>
this was disabled before but
I2631ff687881278ba42edacd237a2130c103b69f
enabled it per default
Change-Id: Ic5a8e50d116cf6b15719668faf055967a6f34e06
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
