The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
Commit 79568f95 (automoc: Add source file to target early to set the
linker language, 2013-02-20) changed automoc initialization to a two
step process. In the first step, the generated source file was added
to the target, which allows the link language to be determined.
However, this bypassed the check for the availability of Qt itself.
At build-time the automoc file could not be generated because the moc
tool was not available to create it.
The solution is to only add the automoc file to the target if Qt is
found.
Previously, GetIncludeDirectories was called before calling
target->AddSourceFile(mocCppSource). Since commit a1c4905f (Use the
link information as a source of compile definitions and
includes., 2013-02-12), the include directories are determined by
the link information.
Valid link information requires that the linker language can be
determined, which depends on the source files languages and the
dependent targets languages. In the case of the no_link_languages
target in the unit test, there are no dependencies and the additional
source file no_link_languages_automoc.cpp is added to the target
at generate-time. That file can be used to determine the linker
language, but it must be added to the target before calling
GetIncludeDirectories.
This should finally fix#13667 and #13762.
Instead of adding special handling to guess whether implicit include dirs
may have been removed, simply make it possible to query the include dirs
without removing the implicit ones.
Alex
On some systems, ${QT_INCLUDE_DIR} is reported by gcc as a builtin
include search dir. Some projects use this information to extend
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
In cmake 2.8.10 now the targets are queried for the include directories
they use. When they return the result, the include dirs contained in
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES have been removed.
In cmake 2.8.9 and below the INCLUDE_DIRECTORIES directory property
was queried, where this had not been stripped.
So, in those projects which modify the implicit include dirs variable,
on systems where ${QT_INCLUDE_DIR} is reported by gcc, this directory,
e.g. /usr/lib/include/qt/, was not given anymore to moc. This made moc
not find required headers, so the build broke.
Simply giving the full CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES to moc
is no solution either, since moc can't handle some of the headers it
finds then (https://bugreports.qt-project.org/browse/QTBUG-28045).
So now cmake checks CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES, and if this
contains ${QT_INCLUDE_DIR}, and the target reports that it uses
${QT_QTCORE_INCLUDE_DIR} but not ${QT_INCLUDE_DIR}, ${QT_INCLUDE_DIR}
is added to the include dirs given to moc.
Alex
This patch sets the FOLDER target property for the automoc target
to the same value as of the actual target. This organizes the targets
in IDEs with folders better.
Inspired-by: Mike Gelfand
Alex
Now automoc always uses GetRealPath() so symbolic links are always
resolved and it doesn't end up with twice the same file, once with the real
path and once with the symlinked path in some setups where the source dir
can be accessed directly and via a symlink
Alex
Until now it was only rerun if the compile definitions changed, but
of course it also has to rerun if the include dirs or moc options
change. Strange that I didn't notice this before...
Alex
Older C++ compilers do not provide a standard std::stringstream.
Use our compatibility interfaces instead.
Also avoid std::stringstream(openmode) signature. Our approximate
stringstream implementation provided when the standard one is not
available does not support the openmode argument.
The variables stored in the AutomocInfo.cmake file were not properly
escaped, so when reading them back they could turn into lists, if they
contained double quotes initially.
This patch fixes this by using cmLocalGenerator::EscapeForCMake() to
escape the variables properly.
Alex
automoc now defaults to strict mode, also with Qt4, i.e. it behaves as
the documentation says by default. I also inverted the switch
CMAKE_AUTOMOC_STRICT_MODE to CMAKE_AUTOMOC_RELAXED_MODE.
Docs and test adapted accordingly.
Alex
ParseCppFile() is the one which is automoc4/KDE4-compatible, and which
becomes a bit crowded. By separating these two it is easier to ensure
that the strict one doesn't get broken accidentially.
Alex
This is again for KDE4 compatiblity. If foo.moc is included, in general
moc should run on foo.cpp. Usually this can't cause problems.
It can only cause problems if moc must run on the header, and the resulting
file must be included in the cpp file, which is the case with the
Q_PRIVATE_SLOT macro.
This makes the test added by Stephen pass.
Alex
-enable the KDE4-compatiblity mode only when using Qt4
-always (except in the KDE4 compat mode) error out if a cpp-file
contains "Q_OBJECT", but does not include filename.moc
Alex
Handing th std::string instead the char* to the find()
reduces the time from 17 to 15 seconds (for a 1000 times loop of a
relatively small file), which is around 10 percent.
Alex
There are multiple/many places in KDE where the developer includes
moc_foo.cpp, and expects moc to run on foo.cpp, instead of foo.h.
He should use foo.moc, but right now this is handled by automoc4,
so we must stay compatible. So support this too, but warn about
it.
Alex
Stephen Kelly
Alex Neundorf
Brad King
Sean McBride
David Cole