920a046 QtAutomoc: Eliminate compiler warning
b00463f QtAutomoc test: Pass QT_QMAKE_EXECUTABLE
e78ce44 Fix automoc with VS builds: apply patch from Bill
71165e9 Silence warning in automoc: use long instead of int
1879bcc Fix build: use std::ios::out|ios::trunc instead of std::ios_base::out
678e124 Only enable the automoc test after checking that Qt4 works
71c29d1 Fix bootstrap test with automoc
afb3edc Fix warnings
add30e9 Fix build: non-void function must return a value
7e6d845 Automoc.cmake is not needed anymore
2963d0b Fix logic which decides when to execute automoc test
77a5c6e Add documentation for AUTOMOC, add initialization via CMAKE_AUTOMOC
bf8ef77 Add a test for automoc
d045fd4 Nicer progress message for the automoc target
50cd6ce Move automoc processing from add_executable/library to cmGlobalGenerator
cbaac2a Remove trailing whitespace
c27607b Refactor SetupAutomocTarget() so it can be run after creating the target
24d9b7d Remove trailing whitespace
58b7fe6 Use cout instead of printf()
72caf4d Add the generated automoc.cpp file to the cleaned files
ddb517d Color output when running moc
9303295 Initialize verbose based onb the env.var.
ace1215 Move code for parsing a cpp-file from the big loop to separate function
735a5bb Fix line lengths
83b730c Add AUTOMOC to the add_library() command
126c6ea Add the cmake module required currently for automoc
de91feb Remove the need to check for .h/.cxx during buildtime
d65689a Add actual automoc code from automoc
d1c0a5f Start implementing skeleton for automoc in cmake
a65011b Start work on automoc: add empty cmQtAutomoc class
For project and target objects, save their ids in CMakeCache.txt.
Hopefully, that will be enough to allow user settings to be saved
across multiple CMake generate operations. Other object types may
also need their ids saved: if so, more code than this commit
will be necessary...
If you had a + in the name of a target with nmake, it created a variable
in the makefile that used + in its name, which is not allowed by nmake.
To make the implementation easier, + is now not allowed for any make
generators as part of a variable name.
Fix problem exposed by recent commit to FindPythonInterp.
If the find "details" has new lines in it, then replace them
with literal "\n" two character sequences so that the string
may be saved as a cache entry that can be re-read next time
CMake runs.
Using the second mode of FIND_PACKAGE_HANDLE_STANDARD_ARGS allows for
checking the version number. Now a user can require a minimum version of
the python interpreter with find_package(PythonInterp VERSION)
The old approach to determine the python executeable chooses the newest
version from _Python_VERSIONS if no additonal versions are passed.
With python it is possible to install different versions side-by-side.
Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe
only installed for testing new features and 2.5 for building and running
his software. Thus the default installation for the user would be python
2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The
new approuch searches first for the the default python executable e.g.
/usr/bin/python on unix and if it can't be found _Python_VERSIONS is
used.
In --find-package mode we can't enable a language, since a lot of
stuff has not been set up, e.g. which make tool to use.
So disable enable_language() in this mode.
Alex
The test "complex" sets the variable CMAKE_BACKWARDS_COMPATIBILITY
to 1.4. When that variable is set, configure_file does not default
to IMMEDIATE mode processing. And so, the output file likely does
not exist yet by the time the next line in the CMakeLists.txt file
is processed. When that next line is "try_compile" on that file,
this is a problem.
Fix the problem by explicitly using IMMEDIATE in the configure_file
call.
This problem was quite mysterious, as it only showed up on the
"complex" test, when the previous commit introduced a CheckSymbolExists
call into the FindThreads module. Which is not even explicitly included
in the "complex" test... FindThreads gets included indirectly only
as a side effect of setting CMAKE_BACKWARDS_COMPATIBILITY to 1.4 and
even then it's included indirectly by auto-inclusion of
CMakeBackwardCompatibilityC.cmake...
Wow. Just wow.
This fixes the problem that otherwise Platforms/CYGWIN.cmake doesn't
know whether it should set WIN32 or not.
Now it uses always the current behaviour.
Alex
QNX has the phtread stuff in the standard library. The best way would
IMHO be to check if a program that uses pthread_* can be successfully
linked without specifying any linker option before trying out the
different flags.
In SystemTools::ClassInitialize, remove call to AddTranslationPath
that was originally put in place to "work around an SGI problem."
This code precluded using CMake effectively in valid directories
under "/tmp_mnt/"
David Cole
Stephen Kelly
KWSys Robot
Bill Hoffman
Björn Ricks
Alex Neundorf
Rolf Eike Beer
Johan Bjork