the problem is that there is no sed command on windows ... so build it
into qmake and invoke that from the generated makefiles. cmake does the
same, after all. ^^
Task-number: QTBUG-33794
Change-Id: Ib7077e18acbc5edd79f714c5779a5ed31ea6c093
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Without that define here moc cannot handle qsystemdetection
properly. While having to touch the mkspecs I also removed
the no longer needed WINRT define.
Change-Id: I0609bd173c7bc14ccdd862afc777d7793dda02b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Using the same approach as, wince qfunctions_winrt
is introduced to replace functions not available
on Windows Runtime by their successor functions/
equivalents.
Additionally this functionality is used for implementing
a fake environment because WinRT does not support
getting/setting of environment variables. The approach
here is also the same that is used for wince.
Change-Id: Ifc3b6b796ab8e8ea41456f4c929f9c3f65f24a0e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
WinRT passes the executable and Appx server info to the CRT main, and
supports several additional activation arguments as well. This handles the
arguments passed to main as well as the case where a modern app is
launched from an external application (e.g. Qt Creator).
Task-number: QTBUG-30198
Change-Id: Ia843e98c7843d5705f5f6d1c809de0b6bcdb5d26
Done-with: Kamil Trzcinski
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
This gives us better consistency across the Qt ecosystem.
Change-Id: Ie12ebb6e8c826ed2e0445eb37de0b79595da41c2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
... except for MAKEFILE_GENERATOR = XCODE. This means the spec no longer
hard-codes g++, and will work regardless of whether the default spec was
clang or g++.
This require us to set QMAKE_XCODE_GCC_VERSION properly for GCC, so that
additional compilation flags passed by Xcode will match the actual
compiler used.
Task-number: QTBUG-31713
Change-Id: If65140a7471cd16f483036742f1d5b86d0485c52
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We'll use nm to get the listing of symbols in the next commit.
The -P option is "portable", which sounds like a good idea. I don't
have access to any of the commercial Unix systems, but I do remember
them printing a different format than GNU binutils's nm.
Change-Id: If6f80624bedaf2b1dabf608e16aa097d9910d739
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The Xcode and SDK settings are expensive to resolve, as we're using
system() calls to resolve them. We now try to detect the presence of
a .qmake.cache file (and inform the user that creating one would be
a good idea), and use the file to cache the various settings after
resolving them.
The Xcode logic had to be moved form xcode.conf as part of the mkspec,
into default_pre/post.prf, so that we could cache() the resolved values.
Task-number: QTBUG-30586
Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Qmake requires the information which extension is
used for static libs on a platform. As the ci for
windows ce is pretty new, this was not noticed before.
Change-Id: I45b0c9c59980cd352371c00aa59502e5a394e337
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Janne Anttila <janne.anttila@digia.com>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
The correct CFLAGS are already present in gcc-base.conf, which is
used as a basis for g++, LLVM, and Clang.
Change-Id: Ic19e28edc55e109ecfe372826b295b817afcd36e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We depend on Xcode for building Qt itself and user application on Mac OS.
The user may have an Xcode install that is not set up properly, in which
case we would fail compilation in mysterious ways. Instead we try to
detect misconfigured or missing Xcode installs as early as possible.
We try to detect if an Xcode install has not been chosen yet, and
if the user has not accepted the Xcode license agreement. We need to
do these checks both in configure, as early as possible, and in mkspecs
on Mac OS, as we need to error out if the user tries to build an app
with the Qt SDK, but with a broken Xcode install.
Change-Id: I4e3a11077a61dc5d4ee2c686d01044a9bb2c1c79
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We always use the xcodebuild/xcrun/xcode-select binaries in /usr/bin,
as these will dispatch to the right binary based on what Xcode version
has been chosen using xcode-select -switch. This fixes an issue where
a tool was in the path from another Xcode installation. We can rely on
the tools as they are present on a clean Mac OS install.
Change-Id: I1d3cc1e92604f9be6d6f14639cb6322234edd696
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This means we have to bump the deployment target to Lion (10.7), as the
LLVM 'libc++' C++ standard library does not support Snow Leopard (10.6).
For iOS the deployment target has to be bumped from 4.3 to 5.0, but we
don't enable C++11 by default yet as it's not tested enough on iOS.
Users who wish to deploy to 10.6 need to build their own Qt,
passing -no-c++11 to configure.
Change-Id: I7b5d20ab002db889d1091a4b7ff600f62caa7f06
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
In order to build Android Qt on Windows via
cmd.exe using the unix makefile generator,
mkspecs/common/shell-win32.conf needs
QMAKE_SYMBOLIC_LINK and QMAKE_LN_SHLIB
Change-Id: I1b3eded66cec06ab131f127c1d46b99124613561
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Instead of unconditionally linking to Foundation, UIKit, and QuartzCore,
we leave the dependencies for the iOS platform plugin, where the libs
are actually used.
Change-Id: Ie8cfad2c8230d1f1af6933b831e443fecb0c93f1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Replace all tabs with proper space characters and consistently align
the '=' characters. The default alignment for the '=' of 25 characters
has been left as is to get a minimal diff. Lines with the '=' further
to the right and those belonging to 'proper code (TM)' have not been
touched.
The work was mostly done using the following python script (might
come in handy again...):
import sys, re
indent_eq = 25 + 0*4 # 25 characters was the most widely used indentation for the '=' character
p = re.compile(r'(\w+)[ \t]*([\-\+]?)(=$|= )[ \t]*(.*$)')
for fn in sys.argv[1:]:
with open(fn, 'r+') as f:
lines = []
nl_count = 0
continuity_indent = None
for l in f:
m = p.match(l)
nl = l
if m:
n_spaces = max(m.start(3), indent_eq - 1) - len(m.group(2)) - len(m.group(1))
if m.group(2) and m.start(2) >= indent_eq-1 and m.start(2) % 4 == 0:
n_spaces -= 1 # left-shift '+=' by one if the '+' is aligned to a multiple of 4
n_spaces = max(1, n_spaces) # we want at least one space before '='/'+='
nl = m.group(1) + ' '*n_spaces + ''.join(m.group(2,3,4)) + '\n'
continuity_indent = nl.find('= ') + 2 if l[-2] == '\\' else None # remember indent on '\\$'
elif continuity_indent:
nl = ' '*continuity_indent + l.lstrip()
if l[-2] != '\\': # check when to stop the continuation
continuity_indent = None
elif l.startswith('#'):
nl = l.expandtabs(2)
if l != nl:
nl_count += 1
lines.append(nl)
if nl_count > 0:
print fn, nl_count, len(lines)
f.seek(0)
f.writelines(lines)
f.truncate()
Change-Id: I1d2870d0a2fe2e30d398c140fe523e69dd20c81b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
unlike unix' mkdir -p, windows' md complains if the directory already
exists. the workaround is a quite complex command, so the so far used
concept for assembling the command line from pieces was replaced with a
single template. for symmetry, adapt the makefile existence check to the
new concept as well.
QMAKE_CHK_EXISTS and QMAKE_MKDIR_CMD were added, with hard-coded
fallbacks (ugly).
QMAKE_CHK_FILE_EXISTS and QMAKE_CHK_EXISTS_GLUE (introduced in 5.0.0)
are simply deleted again.
QMAKE_CHK_DIR_EXISTS and QMAKE_MKDIR remain for legacy reasons, as qmake
emits them into the Makefiles, and custom commands may rely on their
presence.
Task-number: QTBUG-28132
Change-Id: I3d049cb5d26947e5c3d102d0c2da33afb2a95140
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Janne Anttila <janne.anttila@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Qt uses a lot of minor C++11 extensions such as long long, commas at the
end of enumerator lists, and extra ';' outside of a functions, and not all
of these can be silenced, so we build without warnings for C++11 extensions,
since we plan to enable C++11 at some point anyways.
Change-Id: I3ede2fb653c25475a3bd2b860c0c80c6cf6abef5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For Mac OS X we currently specify build tools without an absolute path,
which means we end up using the ones in /usr/bin. This is wrong, we
should be using the tools from the toolchain of the chosen SDK.
For iOS we do specify an absolute path, by resolving the toolchain
path in the iOS makespecs.
To solve the situation on Mac OS X, we move the logic of resolving the
toolchain path to sdk.prf, and share it between OSX and iOS.
For configure we need to duplicate some of the logic from sdk.prf, as
configure pulls out QMAKE_CC and QMAKE_CXX for running some initial
tests and building qmake. The new macSDKify function also solves
the issue of missing sysroot and deployment version in the flags.
Change-Id: Ib1d239c9904cf3ccee5214b313cf6205869a1462
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It is unused in the source code and replaced by Q_OS_LINUX,
Q_OS_ANDROID and Q_OS_ANDROID_NO_SDK depending on usecase.
Change-Id: If8d561540e7583fbac83c0f3506f219c4433e847
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
We want the second member from 'Xcode 4.x', and $$first() gave us
'Xcode' instead of the version number.
Change-Id: Iaf0ed9dc89a03f7918290a61bddade82651ad0f6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The former applies both on Mac OS X and iOS, but 'macx' is specific to
Mac OS X.
ios.conf and macx.conf now share most of their settings in the common
mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so
that any overrides in the device config will apply afterwards. This
means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK.
Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
The only difference between the two is that iOS append @executable_path/
to QMAKE_LFLAGS_SONAME, but since shared libraries are not supported on
iOS anyways, this is not really something we have to care about.
Change-Id: I4797a4dfb94d9b3af03af22618351b98b48f8255
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This is a step towards making mac a shared scope for both Mac OS X and
iOS, while macx is Mac OS X specific and ios is iOS specific.
We'll then move iOS to not include macx.conf, once we make the change
to not have iOS imply macx.
Change-Id: Ic9ce4d597873aa3cf2c981598354733e07db644d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
If there are minor differences later on we can put them in the
mkspecs' forwarding header and/or introduce a macx specific file.
Change-Id: I2a93107838e0d8434c0d444db3064e0a462fa656
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
If the command is quoted, it can contain anything but quotes (we do not
support escaped quotes, so single quotes have to be used). If the
command is unquoted we look for the first closing parenthesis. We used
to do this using .*?, but the greedy modifier '?' didn't seem to work,
so we now use an inverse character set.
Change-Id: I40660ce7aef6a6b6d480292d28da1b079bb161da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We need to figure out where to draw the line when it comes to warning
about unknown compiler (Clang), Xcode, or SDK versions, but for now
building with Xcode 4.6 should not be an issue. We'll have to revisit
this and test with the full set of compiler/Xcode/SDKs we support
before the final release.
Change-Id: Iac3ec3a25c0f7618b2c3714657d147f17f834d97
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
At some point we want to build with C++11 support, but for now we silence
the warning.
Change-Id: I40deb0925d459eaf06e324dddc0a2e9893c57615
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Defining QT_QPA_DEFAULT_PLATFORM_NAME in qplatformdefs.h is not
neccecary, as qconfig.h will already have this define written by
configure.
Change-Id: I89d9191533f6b4e6bfd5eade6cc0dced02b50f81
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Change-Id: Ic04da6063863585665c9133caba0279ba478fbb4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
