If CONFIG option no_include_pwd is set, moc does not add the build
directory to its include path. The path to the generated
moc_predefs.h file is by default relative though, resulting in
moc warnings:
Warning: Failed to resolve include "debug/moc_predefs.h" for moc file xxx myheader.h
Fix this by always making the path to moc_predefs.h absolute.
Task-number: QTBUG-69087
Change-Id: I8ef79c8340f9ebd6b0bba15e026d65ef3c088535
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If MOC_INCLUDEPATH exceeds a certain limit, its content is written into
a file named mocinclude.opt, which is then passed to moc as a response
file. That moc parameter was not properly quoted, and the moc call
failed for paths containing spaces.
Task-number: QTBUG-63197
Change-Id: Ib0542d80ce1bab239e0e6b6e24fadd11007b1846
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When a ObjC++ QObject subclass is listed in the regular HEADERS, qmake
creates a .cpp file. The moc file will then fail to compile, as it
requries ObjC++ headers. Using Q_FORWARD_DECLARE_OBJC_CLASS() can be
used to let the class be parsed by The compiler, but link will still
fail, as the generated methods (e.g. signals) must be built with ObjC++
compiler, in case they have ObjC parameters:
Q_FORWARD_DECLARE_OBJC_CLASS(NSString);
class MyClass: public QObject {
Q_OBJECT
signals:
void objcSignal(NSString * myObj);
};
The canonical workaround for that is including the .cpp file into the
corresponding .mm file. This also offers a compilation speed advantage,
but is somewhat counter-intuitive.
Therefore, we introduce a separate variable which instructs moc to create
.mm files directly.
Task-number: QTBUG-1581
Change-Id: Ia98af58006efd168ea37f3a63c396979e7e81baa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Do not pass /Za to MSVC to generate moc_predefs.h, because this option
is incompatible with compiler options like /fp:fast that may be
user-specified.
The /Za option added, because moc failed parsing header files that
contain MSVC extensions. Moc was fixed in 94a2aec0, and we can safely
remove the /Za option.
Task-number: QTBUG-58391
Change-Id: I9791224b1773d0f81d2bbb7915787a7c5e68430c
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It seems this change is preventing us to integrate qt5.git in '5.9'
This reverts commit c3030d7163.
Task-number: QTBUG-61204
Change-Id: Id98afaa23be0a8dd6f2c54a899f46542c65436aa
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Because we obviously don't support Microsoft's extensions in C++. This
is required because some MS headers have code that isn't proper C++,
like iso646.h:
#if !defined(__cplusplus) || defined(_MSC_EXTENSIONS)
#define and &&
Do not pass /Za to MSVC to generate moc_predefs.h, because this option
is incompatible with compiler options like /fp:fast that may be
user-specified.
This reverts commit e1a70ce4 and re-fixes the issue similarly to commit
d72ac3f3.
Task-number: QTBUG-58391
Change-Id: I5c0143283afed09f98200806c87259c039c00ae1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Sometimes, users need to add compiler flags to QMAKE_CXXFLAGS that
aren't supposed to be passed to the predefs dump. That's especially true
for -include options, as that would change completely what's
defined. Not to mention that -include is a preprocessor option and
shouldn't be in CXXFLAGS in the first place (Automake has CPPFLAGS, but
qmake only has INCLUDEPATH and DEFINES).
[ChangeLog][qmake] Added the ability to suppress the collection of the
compiler predefined macros for moc's use. To disable the collection, use
CONFIG += no_moc_predefs.
Task-number: QTBUG-58857
Change-Id: I4139d5f93dcb4b429ae9fffd14a34d49825d9b85
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This re-fixes commit d72ac3f35f, which
simply removed the #define but did so at the wrong place. Instead of
forcing the macro to be removed, let's simply not have it defined in the
first place.
Change-Id: Ie6dbad9bbbd9488887e8fffd148dd67d9a31b32e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
In VS builds the default name is the first word of the command, in this
case "cl". Use the generated file name instead.
Change-Id: I8f0039eeae045f8b9a13caea8bd3e338bbe2ed17
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
we can't use $(QMAKE) after all, as this breaks with the visual studio
generator. so massage $$QMAKE_QMAKE into the final form manually
instead.
supersedes 591d9588f in amending 2b6bcd5ff.
Change-Id: I8c7a6c43f9668d88c1cc968dbf5614240f16239a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the variable is converted to a format suitable for makefiles only after
the project was read. to access it, one needs to use the exported
makefile variable $(QMAKE).
amends 2b6bcd5ff.
Change-Id: I5eddff4bebbbcf461b565d5033d17a8daff1e6f4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
since 9ff1310af, the variable's contents are simply added to SOURCES,
and the variable is not cleared. and qmake does not de-duplicate ...
Task-number: QTBUG-53905
Change-Id: I3e551d21cbbd2d0cbfbf7aa7efaa5babac112f9d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
There's no reason for this to be separated, regardless of the
support status of i386 macOS builds. Additional architectures may
appear in the future (and currently there's actually 3 - i386,
x86_64, and x86_64h for Haswell CPUs). So this feature could be
used to get combined generic x86_64 and Haswell builds. Some
system libraries appear to have an x86_64h slice in Sierra.
[ChangeLog][Build System] Support for universal binaries on macOS
has been re-introduced.
Change-Id: I1c89904addf024431fdb3ad03ea8ab85da7240ad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This patch moves towards a more sensible layout for UIKit platforms,
where both the device and simulator architectures for binaries are
combined into a single Mach-O file instead of separating out the
simulator architecutures into separate _simulator.a files.
This approach is both more common in the iOS ecosystem at large and
significantly simplifies the implementation details for Qt, especially
with the upcoming support for shared libraries on UIKit platforms.
This patch takes advantage of the -Xarch compiler option to pass the
appropriate -isysroot, -syslibroot, and -m*-version-min compiler and
linker flags to the clang frontend, operating in exactly the same way
as a normal multi-arch build for device or simulator did previously.
Exclusive builds are still enabled for the xcodebuild wrapper Makefile,
which builds all four configurations of a UIKit Xcode project as before,
as expected.
A particularly advantageous benefit of this change is that it flows very
well with existing Xcode workflows, namely that:
- Slicing out unused architectures is handled completely automatically
for static builds, as an executable linking to a library with more
architectures than it itself is linked as, the unused architectures
will be ignored silently, resulting in the same behavior for users
(and the App Store won't let you submit Intel architectures either).
- Removing architectures from a fat binary using lipo does NOT
invalidate the code signature of that file or its container if it is a
bundle. This allows shared library and framework builds of Qt to work
mostly automatically as well, since an Xcode shell script build phase
can remove unused architectures from the embedded frameworks when that
is implemented, and if Qt ever starts signing its SDK releases, it
won't interfere with that either (though binaries are just resigned).
Change-Id: I6c3578c78f75845a2fcc85f3a5b728ec997dbe90
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
get rid of the entirely superfluous stock "Aborting." messages -
the event triggering the exit has already reported the problem.
Change-Id: Ib9dfb9e4212f60eceb2ea432cdf56c5a8afe9d65
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
C preprocessors augment their standard list of include paths from the
environment: Unix preprocessors use $C_INCLUDE_PATH (for C) and
$CPLUS_INCLUDE_PATH (for C++), plus CPATH for both, whereas MSVC uses
the an environment variable simply called "INCLUDE". Handling this for
MSVC is particularly important because the VCVARSALL.BAT script sets the
necessary #include paths in the environment for important things.
Without that being parsed, moc won't find some #defines, like
WINAPI_DESKTOP_FAMILY.
[ChangeLog][moc] qmake and moc now cooperate to use the Visual Studio
environment variables (set by the VCVARSALL.BAT script) to find system
include files. A possible consequence is that moc parses application
headers slightly differently, depending on #if conditions that depended
on macros that previous versions had not seen #define'd. Implementers of
other buildsystems are advised to pass the --compiler-flavor=msvc option
to moc.
Change-Id: I7e06274214d1939b0124e5b4bf169cceaef9ca46
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
In order for moc to properly parse #ifdefs and family, we've had
QMAKE_COMPILER_DEFINES as a list of pre-defined macros from the
compiler. That list is woefully incomplete.
Instead, let's simply ask the compiler for the list. With GCC and
family, we use the -dM flag while preprocessing. With ICC on Windows,
the flag gains an extra "Q" but is otherwise the same. For MSVC, it
requires using some undocumented switches and parsing environment
variables (I've tested MSVC 2012, 2013 and 2015).
The new moc option is called --include to be similar to GCC's -include
option. It does more than just parse a list of pre-defined macros and
can be used to insert any sort of code that moc needs to parse prior to
the main file.
Change-Id: I7de033f80b0e4431b7f1ffff13fca02dbb60a0a6
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.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>
For normal #includes, moc simply ignores the missing file, but it could
generate problems later. It's a problem when the file being sought is
the FILE from plugin metadata. A very good example of this is Qt
Creator:
coreplugin.h:49: Error: Plugin Metadata file "Core.json" does not exist.
Change-Id: I16af04b477f52c6bd53c14147ec777b358dfdf50
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this hasn't happened yet at this point of processing, so we'd pass bogus
paths when shadow-building.
Change-Id: I9f9633c0dbc2aadeff1eb555a8e598ddb0837e37
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This commit will make qmake use -isystem automatically for any
compilers that declare support for it for any paths that are listed in
QMAKE_DEFAULT_INCDIRS.
Change-Id: I36fefc6d5bba61671f65669f0ea42704b3c3cf31
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Those paths need not be in INCLUDEPATH: qmake always adds them to the
compiler command-line and we should match the behavior if we expand
INCLUDEPATH here.
Change-Id: I89508d15ac534b54ae873a42c4ad9764408042b5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Replaced tabs with spaces to align with space-indented code
and removed some trailing whitespace.
Change-Id: I4930afc3df206ef8ee96de3e69f0d69fc4a1c77c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
unlike the real compiler, moc does not have these directories built in,
so it would not find headers from a system install of qt.
Task-number: QTBUG-28870
Change-Id: I86f18cdc8953145190163746dae59f4e784f2d78
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the surrounding TEMPLATE == vc* scope already implies vcproj, as dsp is
not supported any more.
Change-Id: I68363aca62e21135f42572040ccc7b189dcf32c8
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
there won't be terribly many projects relying on it. now's the time to
find out for sure ...
this reverts commit 3279b07302fde0eb14f9b197c9ad2e14d512817e
Change-Id: Id36687ab3bfc7dd5ce35b584621a8f5b3ee00fc9
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the problem this (probably) tried to solve has been solved via ordered
builds a *long* time ago.
Change-Id: I84c58076c864735eea4210ec60aa060fe3e5d97e
Reviewed-by: Joerg Bornemann <joerg.bornemann@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
