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>
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>
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
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>
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 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