This change will be needed during migration from QByteArrayData to
QArrayData.
Change-Id: I0c8d6f9ed3ef7c33af62736af55259a8f9a70c0f
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The nice side-effect of having Q_ASSERT use the condition twice is
that we break code that has side-effects.
Change-Id: Ia0b7ed2a8030c8e222612af95eb2d58671433110
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The only use of QUrl in qmake, moc, uic and rcc is due to QVariant's
internals, so let's disable it. This means those binaries are now
probably a lot smaller since the parsing and IDNA code don't need to
be present.
Change-Id: Ie156b0817d119b2ba5d3dcb9712a9fea2ee7d4a1
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
QStringBuilder will be enabled by default so qmake should build with it.
qstringbuiler.cpp has to be compiled in just for the convertFromAscii
(The alternative was to build with QT_NO_CAST_FROM_ASCII, but that would
be too much work)
Change-Id: I1fbeed7ed8a9d3bc38ef591a687c50644980e2fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this is a complete bastardization of the concept and breaks the (unused)
debugging feature to create proper unix makefiles under windows, but
apparently it permits cross-compiling unix targets under windows.
Change-Id: I4ee95a20e7d6a6b2063ec7aa22f52c1a97d78a77
Reviewed-by: Oliver Wolff <oliver.wolff@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Commit 8e5eb1bddc introduced the assumtion that mkspecs are
immediately below the mkspecs directory itself. This is not true for
e.g. unsupported/blackberry-armv7le-qcc.
This commit restores qmake's ability to find the "root" of the mkspecs
collection no matter how deeply the actual mkspecs are nested.
Task-number: QTBUG-24665
Change-Id: I98faaf8e6ae7b8524277aea6c17e685e507e37b3
Reviewed-by: Sean Harmer <sh@theharmers.co.uk>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this makes the "sysrootable" properties more magic, with the raw
versions being omitted from the qmake -query output and automatically
falling back to the "cooked" variant if there is no sysroot set.
this makes the "normal" qmake -query less noisy. this will become even
more obvious when i add more "overloads" of the properties.
Change-Id: I08000986427264ec6238c8fe0a77f5cecdbf1201
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the feature is rather obscure and unlikely to be used by anyone.
Change-Id: I2dfb4ca4d5d1f210d385c013f46bc6389fd6ea2d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
make is perfectly capable of doing shadow builds
Change-Id: I7e1c27cddc385b7a17ae5645b9cd26fa56d2f029
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this was a somewhat magic support for sysroots, automatically rewriting
a number of path-holding variables. this was (as usual) completely
undocumented, extremely fragile, and we are coming up with something
better now anyway.
Change-Id: I045910f532cb3efc839ea81c7a48f8db695e4092
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
there is totally no reason to call it unless the project is actually
used for makefile generation, and the excessive calls actually mess up
things.
Change-Id: Idb7912a5404f6054010d2f29cce820a167de4f6f
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
the project build root can of course be empty - if there is neither an
mkspecs/ nor a .qmake.cache - or no project in the first place (-query).
Change-Id: I9595b0b4ad80a9086dcd48c9ae62b3e8bd1b6f2f
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
The -spec argument was interpreted as a relative directory as
soon as it contained a slash. Fix this by checking if the
directory exists before attempting to interpret it.
Change-Id: Ide8f0418abc719b0be582d2d72642a141f6c6dea
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
This will be used later on as a base class for QTemporaryFile and
QSaveFile.
Change-Id: Ic2e1d232f95dc29b8e2f75e24a881ab459d3f037
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
clean up the somewhat convoluted code paths which forced re-evaluation.
now that the spec+cache are evaluated in a completely clean context
anyway, there is no point in re-evaluating them for build passes.
Change-Id: I12279083238e9ca7028af97f45e2638c8dc715b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of initializing base_vars with the original's vars, initialize
vars itself. this has two consequences:
- there is no need to call read(0) to initialize vars
- one cannot usefully call the complex read() anymore, as that would
re-initialize vars from base_vars
this is much closer to an actual copy than the previous "seeding with
existing project".
Change-Id: Ib007bc5b779aedb680a27329aa578f7c604a4308
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
load()/include() with a target namespace would inherit the current
context. however, if you source a project with all bells and whistles,
this makes completely no sense and may be actually counterproductive.
infile()/$$fromfile() would have interited only the functions from the
current context. that was only a hack to support abusing them.
Change-Id: I2e992b923d9e5b0e5056001ca49b35de573abc63
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is a hack from the times when these functions were (ab)used to
inspect proper project files, but the inclusion was done with a clean
project, so that the included files did not have any functions to work
with.
Change-Id: I19925e8ead597ca38df040000c183e368b32c06d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
merge them into before_user_vars. they are evaluated right after another
anyway.
Change-Id: I11859284b363fee01233f6e20989444fef711d0d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
don't inject the build pass specific variables into the project even
before evaluating the .spec file and the .qmake.cache. they are not
supposed to base configuration on that - feature files should do that
later.
the immediate advantage of this is that base_vars is never manipulated
upfront any more, which allows for cleaner setup paths. also, we can do
more caching of the spec+cache contents.
Change-Id: I19d7f8bec1fb7c3b54121e26794340b287055ebf
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
instead of messing with the Option singleton, add a way to inject
extra config values into QMakeProject.
Change-Id: Ia347dcc38af2c72913e30ebf5c2b4044f93b4f5f
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I07c66d95a9ae01a664cec17564995311fb78ec9b
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that way qtbase will find its spec without hacking .qmake.cache.
note that passing "-spec default" on the command line would have already
triggered the normal path, so artificial limitation did not even provide
safety against abuse (it is arguably pointless/counterproductive for
other projects than qtbase to have a default spec).
Change-Id: Ib0c3e6498fd70cd6f9561951d72a47165878bb33
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
nothing to be found in <sourcedir>/include.
neither in <builddir>/src/corelib/xml.
Change-Id: I381391a64542dc2ac7b421b6646c60a1b7a14639
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
makes the file a "tad" more concise
Change-Id: I81d9721942890659ac93b32f5988f9c005c88e87
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
the only difference is in the copy & del commands. the msys tools are
tolerant about windows paths, so this just works.
the in-makefile variant detection is stolen from tools/configure/.
Change-Id: Ia283c1fe2e2aaa8cd5b1dfd7ae29244115f07d65
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of being a variable added to the makespec (via qconfig.pri),
QT_SYSROOT is now a property.
the QT_INSTALL_... properties are now automatically prefixed with the
sysroot; the raw values are available as QT_RAW_INSTALL_... - this is
expected to cause the least migration effort for existing projects.
-hostprefix and the new -hostbindir & -hostdatadir now feed the new
QT_HOST_... properties.
adapted the qmake feature files and the qtbase build system accordingly.
Change-Id: Iaa9b65bc10d9fe9c4988d620c70a8ce72177f8d4
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that is, spec/../features/ (i.e., mkspecs/features/) - and not any
directory up to the root.
Change-Id: Ie5fdf2898fba5ac93583571edc24629471604798
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
make it table-driven and have it cache the immutable values from
QLibraryInfo.
Change-Id: I07ed89152aa964bc9edf4436ee7c42f99cc6bcd3
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
moving the detection of .qmake.cache to the qmake startup had the side
effect that a suddenly popping up cache would not be picked up by
nested projects any more.
this is not supposed to work in the first place, but the syncqt hack for
building against non-installed modules relies on it. until we have
cleaned that up properly, we need a way to notify qmake about the
appearance of the cache file.
Change-Id: I450646b936e3bb2ef2ed3aba05df58e521ccdc61
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
This adds support for XCode 4 into qmake and also indirectly fixes a
couple of problems that are relevant for XCode 3.2 too
Task-number: QTBUG-17247
Change-Id: I722470ad1854bd740cbbd28ff4956057a0e1906b
Reviewed-by: David Forstenlechner <dforsten@gmail.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
(cherry picked from commit b5871311457ca97816c0abbb8b935570bbfb657c)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
there is no reason for doing that. there is even reason for *not* doing
it (the enums running out of sync).
Change-Id: Ieb7d015ca497a6675cc85da4c2e0af0c1533dd7a
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
This implements replacements for win32 makefile generators similar
to the replacement functionality in unix makefile generators.
To enable Makefile code generation for replacements in win32 makefile
generators, you must set QMAKE_STREAM_EDITOR to e.g. sed.
When building for win32, sed is normally only available in the
mingw/msys build environment and when cross compiling on unix.
In these cases QMAKE_STREAM_EDITOR is set to sed in qmake.conf.
For other win32 build environments QMAKE_STREAM_EDITOR is not set
in qmake.conf and the replacements Makefile code is not generated.
Change-Id: Ie5de5d517eafaeaa2544f1e972aec3fe11d0a6f1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
qmake would look for mkspecs/ in the directory containing the current
project file. this makes completely no sense with recursive projects:
a) nobody would make per-project specs and b) specs meant to be global
would not be found.
consequently, we look for a project root when starting qmake and use
only that directory.
if .qmake.cache is found/set, we assume that to be the project root.
otherwise, we search for mkspecs/ the same way we search for the cache -
just to up until we find one or hit the root. if we are shadow-building,
search the build dir as well.
Change-Id: Ie66b189a40c21203d956e681cbef44a89f98cd17
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is way more predictable than resolving it later.
Change-Id: I0ce27977b795bde9235e1d51d6f2d0d917f2398c
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I11ef30a8227afed06e58e64e65809dba25e81567
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it's generally redundant with DataPath which we already look into.
this is consistent with where mkspecs are looked for.
i don't think anyone will notice this "loss" ...
Change-Id: Iab7c35cc22ba53e1005f26b5d85d41cf4dafad07
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
no point in saving the context when we are not actually modifying the
current context.
Change-Id: Id6f51a163e86bdf402aa0713737b655db68e7ee8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
we already initialize it before parsing a project. if a project is daft
enough to clear TARGET, it does not deserve differently than breaking.
Change-Id: I6c727bc27d72a00e84b676ae3c169024bdb2d929
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
The QByteArray::operator const {char,void}*() implicit
conversions are a source of subtle bugs, so they right-
fully can be disabled with QT_NO_CAST_FROM_BYTEARRAY.
const char *d = qstring.toLatin1(); // implicit conversion
while ( d ) // oops: d points to freed memory
// ...
But almost no-one ever enabled this macros in the wild
and many were bitten by these implicit conversions, so
this patch deprecates them.
I would have liked to remove them completely, but there
are just too many occurrences even in Qt itself to hope
to find all conditionally-compiled code that uses these.
Also fixes all code that needs to compile under
QT_NO_DEPRECATED (in qmake/, src/tools/).
I984706452db7d0841620a0f64e179906123f3849 separately
deals with the bulk of changes in src/ and examples/.
Depends on I5ea1ad3c96d9e64167be53c0c418c7b7dba51f68.
Change-Id: I8d47e6c293c80f61c6288c9f8d42fda41afe2267
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The libName that is used in pkgConfig files should include the
TARGET_VERSION_EXT.
This is needed because in Win32MakefileGenerator::fixTargetExt(),
the TARGET_VERSION_EXT is added to the library name.
In Win32MakefileGenerator::processVars(), if TARGET_VERSION_EXT is empty,
it is set to VER_MAJ.
On platforms != Windows, TARGET_VERSION_EXT does not seem to be used.
We probably got away with this so far because pkgconfig files generation
for win32 was just added in 4.8 and nobody uses them yet, and because on
platforms != windows the TARGET_VERSION_EXT is not used.
Change-Id: I56f239e389f0ef926030e4c2376cadd92c4f673c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
base_vars["QMAKESPEC_ORIGINAL"] is not guaranteed to be set the first
time resolveSpec is called, since an include() can wipe it out. Change
it so that resolveSpec is called repeatedly until some
QMAKESPEC_ORIGINAL is set.
The code which attempted to remove all of the path up to the last / was
incorrect and must have been dead code (or its wrongness didn't matter)
until now.
Change-Id: I2b31ae10fc284ac7293c3cd95e5a2fd503ca7ab0
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
It was the result of miscoordination between Andreas Holzammer and me,
duplicating the functional change of commit
ea2c9f764f.
This reverts commit 8b7a9b4898.
Change-Id: I9a47746c1c12ca00b2dc5c5d50e99f9bf990e3f7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
This abstraction imposed serious performance penalties and is being
dropped from the public API.
In particular, by allowing file names to be arbitrarily hijacked by
different file engines, and requiring engines to be instantiated in
order to decide, it imposed unnecessary overhead on all file operations.
Another flaw in the design with direct impact on performance is how
engines have no way to provide (or retain) additional information
obtained when querying the filesystem. In many places this has meant
repeated operations on the file system, where useful information is
immediately discarded to be queried again subsequently.
For Qt 4.8 a major refactoring of the code base took place to allow
bypassing the file-engine abstraction in select places, with
considerable performance gains observed. In Qt 5 it is expected we'll be
able to take this further, reaping even more benefits, but the
abstraction has to go.
[Dropping this now does not preclude that virtual file systems make an
appearance in Qt at a later point in Qt 5's lifecycle. Hopefully with a
new and improved abstraction.]
Forward declarations for QFileExtension(Result) were dropped, as the
classes were never used or defined.
Tests using "internalized" classes will only fully run on developer
builds. QFSFileEngine was removed altogether from exception safety test,
as it isn't its intent to test internal API.
Change-Id: Ie910e6c2628be202ea9e05366b091d6d529b246b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
resolve only once, in particular on unix.
Change-Id: I090698fc6029322a3a16d179d461af3e8336f6ad
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
there is no obvious reason why this should happen. if base_vars is used
again, the user configs will be parsed again, too.
Change-Id: Ib56e01a468cdb5e81d610bcaf0163bf730cbae05
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
-O2 triggers an optimizer bug where compiling unixmake*.cpp would take
several minutes each. -O1 is not measurably slower, so use that instead.
Change-Id: Ibf8abbecdd69e35cef800841f781543121168f76
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this brings some clarity which combinations are actually possible, which
allows for some optimization later on.
Change-Id: I930027e426c5f9abea8d21eb1ebaa39bd29787b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Check the QT_OUTPUT_PATTERN environment variable in the default
message handler to customize the output of messages. Following
place holders are right now supported:
%{message}, %{type}, %{file}, %{line}, %{function}
The original cleanupFuncinfo was written by Thiago Macieira.
Change-Id: I6ad25baaa0e6a1c9f886105d2a93ef3310e512a9
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: David Faure <faure@kde.org>
This change is needed because msvc2010 tools have a '\' character at
the end of environment variable VCINSTALLDIR. This variable on msvc2008
does not have this '\' character at its end. Without this change
QMAKE_TARGET.arch on msvc2010 x64 evaluates to x86 instead of x86_64.
Task-number: QTBUG-22686
Change-Id: Ifba833e9361c97568b8b3de9976023e8537b208a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Disable optimization for getProjectUUID() as it triggers
ASSERT: "&other != this" at qstring.h:720 with -O2.
Change-Id: I51b31d4318ba9be187c186623099171d8f48235b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qmake-generated Makefiles since 4.6 (according to bug report) contain
recursive qmake invocations with absolute paths to .pro files, where the
absolute paths are not escaped.
Task-number: QTBUG-11776
Change-Id: I49772c7d9147efea3bb7b9623c61d92aa0bb6857
Reviewed-by: Jonas Gastal <jgastal@profusion.mobi>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
When installing extra binaries the paths where not being escaped,
causing stripping and deleting to fail when dealing with filenames
that contained one or more spaces.
Change-Id: Iba4517b1110f6af30f7e2662cb86024a8b7b81f7
Reviewed-by: Kurt Korbatits <kurt.korbatits@nokia.com>
Reviewed-by: Lincoln Ramsay <lincoln.ramsay@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this should make the evaluator quite a lot faster. the total win for
qtbase/src is only 6%, though.
i made some effort to avoid that output files get randomized. however, i
didn't bother to keep debug output sorted.
Change-Id: Id9cef4674c0153c11ebbb65cb63bf8c229eb56e3
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
For the debug configuration the optimization should be turned off.
Task-number: QTBUG-23421
Change-Id: Ib63e0c51f9ab31180ff8ee01a1f6c57ab77e390e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Setting QMAKE_CFLAGS+=/MP in a project file did not work for VS 2010.
Task-number: QTBUG-23490
Change-Id: I39c349bf8dc2a4add2f32a430a245a20cc54147e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Silence MSVC warnings about forward-declarations as class
in the metatype system.
Change-Id: I676662e5919585e98c87413fd8360d6f41f73631
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
That define is not used anymore when building qmake.
Change-Id: I6a478cf4bb6cc8dfe87a3cc96f1d520b08e4ba6f
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This solves the problem of two source files in the same project
having the same name, which ends up with colliding object files.
It also solves issues with moving files around in the source tree
when the GNUmake option is used together with gcc_MD_depends,
where the dependency file would end up with a dependency to the
old source location.
We already have object_with_source option, but that does not play
nicely with shadow-builds. The new option tries to keep the same
hirarcy in the output dir (while still respecting OBJECTS_DIR),
as the sources. Any source with a path outside of the root project
directory (absolute or relative, ../../foo.cpp), will be put inside
the objects directory with the full path appended.
Change-Id: I0c96291974f4801f4c55a26485d512b15c144c00
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Extra compilers may define a depend_command that's used to generate
dependencies for each input. When GNUmake was enabled we failed to
run this command, which was affecting resource files, as resource
dependencies are handled by an extra compiler defined in resources.prf.
The result was that changes to resources included in a resources-file
did not trigger a re-run of qrc and subsequent recompile of the
resource object file.
We must always run these custom dependency commands, even when GNUmake
(and the extended gcc_MD_depends option) is enabled, as GCC is only able
to handle regular #include-type dependencies. Hence, the check for the
'include_deps' flag was removed from doDepends(), and the check for
GNUmake was moved to the one place where it still made sense -- when
deciding whether or not to do recursive dependency checking.
Change-Id: I5ddb75c873120c90f798808efc52e81500786301
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
And enable this configuration option for the resource compiler. This
results in a re-run of qmake whenever you touch a qrc file, which is
needed to keep the dependencies up to date. Otherwise you might end
up in the situation where you add a file to a qrc, edit the file some
time later, but a rebuild does not regenerate a cpp file and compile
that, so the final binary is stale.
Technically this dependency problem is present for all source files,
and qrc files are no different than any cpp file that you add a new
header #include to, or adding a Q_OBJECT macro to a header. To pick
up these changes we have to re-run qmake, so that qmake can run its
internal dependency checking, and any extra compiler dependency
commands.
The reason we're making this change for rcc files it that conceptually
people treat them as a "project" files, and expect them to behave similarly
to .pro or .pri files, in that editing the file will invalidate the
makefile. In practice this is often what happens when adding new
headers, as you touch the project file when changing the HEADERS
variable.
Task-number: QTBUG-13334
Change-Id: If69149678e7fba6d812d31dcc17877427f9a6122
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
Tests will install under $$[QT_INSTALL_TESTS].
TESTDATA may be used to install additional testdata required by the
test.
The default install rule may be disabled by
CONFIG+=no_testcase_installs.
Change-Id: I204de60c8e844775906ffd016ca50bffbb414142
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
qmake generates .gpj project files for INTEGRITY.
Calls to moc on headers or code that do not produce actual output cause
a Note to be generated. This is considered as an error during build by
the Green Hills gbuild build tool.
-nn can be added to not generate that note when no output is generated.
This was already done for headers in util/integrity/qt.bod, but it was
not there yet for .cpp files.
Merge-request: 2693
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
(cherry picked from commit 480b2f4c79160afaac7934936d3ae6ea382ae2bb)
Change-Id: I480b2f4c79160afaac7934936d3ae6ea382ae2bb
gcc 4.6 becomes the minimum required version in Qt 5.
See also d4150975af620e2889cc58bd476bac6b4d101db3
in Qt 4.8.
Change-Id: If66ce0be755263c20b0a4371523c6590592d962d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Many enumerator values were not handled in msbuild_objectmodel.cpp. For
each unhandled value, add a case statement that simply breaks.
Change-Id: I018fc5e641200568c88ccc6acb3f5b6ee6b3fd6f
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
It's nicer to do:
SUBDIRS += foo
foo.CONFIG = no_default_target no_default_install
then to omit foo from SUBDIRS because a Makefile is still produced
but "make" and "make install" don't descend automatically.
The vcproj generator doesn't know about this. This patch gets it to
check for no_default_target and then it simply ignores the directory.
Change-Id: I127bea79143c101612afb0e9c6603d3b065c7c56
Reviewed-by: Oliver Wolff <oliver.wolff@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Using CONFIG+=GNUmake will enable dependency tracking using included
dependency files, but will use an implicit makefile rule to generate
each .d file.
We now support an additional CONFIG option, gcc_MD_depends, that
instead passes the -MD flag to a GCC (compatible) compiler. This
will generate a .d file as a side-effect of the normal compile
step.
Change-Id: Ib6ce1d93e7f07e316a345bf12aa6f2b4e9a6415d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Sometimes you will include "moc_foo.cpp" from a a cpp file, not to tell
qmake to run moc on it (that's handled by having foo.h in HEADERS), but
so that the moc'ed sources are compiled as part of foo.cpp instead of a
separate compilation unit, or if the moc'ed sources need defintions from
the cpp file.
The dependency logic for CONFIG+=GNUmake failed to take this case into
account, resulting in failures to find files when generating dependency
information for those files.
Change-Id: Iac00424e2d196b518b1ef576d7567335b8ff24f0
Reviewed-by: Simon Hausmann <simon.hausmann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Previously we were generating include lines based on the relative path of
the source file, which resulted in the .d files being placed in the source
dir as well. We now expect the .d files to live in the output dir, but keep
the dependency from the .d file to the original source file.
Before:
.deps/%.d: %.cpp
-include .deps/../../src/foo.d
After:
.deps/%.d: ../../src/%.cpp
-include .deps/foo.d
Change-Id: I749adeb671cf8424f0849521c5bb1489eb3e76d5
Reviewed-on: http://codereview.qt-project.org/6455
Sanity-Review: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
a qmake invoked with a relative path would not find qt.conf, because it
already changed CWD, which would confuse our copy of
QCoreApplication::applicationFilePath() (see also QTBUG-21381).
we already have the absolute path to the qmake executable in
Option::qmake_abslocation, so just use it.
(cherry picked from commit c378e16e57e8ce2255116e7fdb5436524cccb8c7)
Change-Id: Icfe4254722e0855f6755b639f4c86f15bc7323ba
Reviewed-on: http://codereview.qt-project.org/4565
Reviewed-by: Harald Fernengel <harald.fernengel@nokia.com>
this was just a merge artifact
(cherry picked from commit 4ac87b7042f7b08e8b427e21d74aa8d224b186bc)
Change-Id: Ifa0638982fe48fda2e8d9aa7ee43029187330f02
Reviewed-on: http://codereview.qt-project.org/4574
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
If you ran qmake with 'qmake -r', default_pre.prf would only be run once
while default_post.prf would run for every sub-project.
This makes it more symmetrical and correct.
Change-Id: I1d096c38dffb16f1d256c511ed9e2912cfaefe66
Reviewed-on: http://codereview.qt.nokia.com/1716
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
"default" was used a very long time ago, and it's time to let it go.
Change-Id: I230573ef778789f6e1a5a7df3543e660392da39b
Reviewed-on: http://codereview.qt.nokia.com/1746
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the 'item' reference may become invalid inside the loop.
this approach was chosen (instead of making 'item' a non-reference) to
keep the code more in sync with creator (where the string type is more
complex).
Change-Id: I60a4b0654dc47c0e3466d43904c358eb7e3e64e2
Reviewed-By: Marius Storm-Olsen
Reviewed-on: http://codereview.qt.nokia.com/1702
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
make it a proper topological sort. before, it could not resolve diamonds
correctly.
Change-Id: I17ffd81020ab36e7e5dbcfd120793ba8d9c6cf18
Reviewed-on: http://codereview.qt.nokia.com/1435
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that's common practice for the expand functions, and that one isn't even
particularly big
Change-Id: I66c22e11edb66bd00d211fc1282eb75f5dd4832d
Reviewed-on: http://codereview.qt.nokia.com/1456
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
... and re-add a real $$resolve_depends(), just in case.
Change-Id: I489d6056546340ce95280fe7fd571e30c14470e7
Reviewed-on: http://codereview.qt.nokia.com/1455
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
it needs to go from highest order to lowest order.
that's not relevant unless doing static linking.
Change-Id: Ieb69e3949b4d9cc2d2a62f5661f31e3dc88ac882
Reviewed-on: http://codereview.qt.nokia.com/1454
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is braindead, but it's consistent with the rest of qmake and more
performant. and the argument error message claimed it already anyway.
Change-Id: I973368acc6ffbff17107085ccd68b0334cc3e681
Reviewed-on: http://codereview.qt.nokia.com/1436
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
The distinction between 'examples' and 'demos' is completely blurred at
this point. We've decided, with the SDK people, to scrap the existing
terminology in favor of the word 'example' only -- distinguishing
between code snippets, walkthroughs, "demonstrations" can be done
via keywords or some other method.
Removing QT_INSTALL_DEMOS from all .pro files in Qt is still in
progress.
Change-Id: I86fc0e40d54baa54c5641fc6acbd8b67e4ad2789
Reviewed-on: http://codereview.qt.nokia.com/1034
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Recursive QMAKE_EXTRA_TARGETS were omitting the `-f' option to make.
This would break in the case where the correct makefile was not named
`Makefile'. The included autotest demonstrates the problem.
Note that this was fixed for normal targets back in 2005
by faac7bd178654fd67a6f3f9cf4f6f2605071448d (p4 202370), but was not
fixed for extra targets.
Reviewed-by: ossi
(cherry picked from commit 96a3bf7a8bbc1e5361e16cbeeceb4be674b88c30)
The template type "aux" is intended for projects that do not require building anything, but may need to install stuff (e.g. applications with QML entry point).
Reviewed-by: Joerg Bornemann
(cherry picked from commit 56443421cb5e537e60abd7ced42c9ebf587683fe)
This will allow us to expose private headers in a controlled manner,
and ensure that they are not used by accident. This also means that
we internally will have to enable the private headers for the
modules we wish to use in the project.
This function calculates the topological order of variables.
We will use it to determine which and in what order to link
module libraries.
The function is not tied to libraries/modules only, but requires
the variables to be ordered to have their dependencies in the
[prefix]<var>.depends subvariable.
Due to the recursive nature of the algorithm it was just much easier
to implement it directly in C++ rather than in a qmake-language
function.
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
