a3815e6 -fix line length
9110d0e Eclipse on OSX: improve handling of framework include dirs (#13367)
d97b385 Eclipse on OSX: fix handling of framework include dirs (#13464)
In commit b237dbd8 (Xcode: Fix object library references in
multi-project trees, 2012-08-03) we accidentally enabled CXX in the
subdiretories of this test by invoking project() with only one argument.
The top-level directory of the test enables only C, so do this in the
subdirectories too.
Instead of reading the whole file using file(READ) and later matching on the
whole file use file(STRINGS ... REGEX) to get only those lines we are
interested in at all. This will make the list much smaller (good for debugging)
and also the regular expressions will need to match on much smaller strings.
Also unset the content variables once they are not used anymore.
If the depender (e.g. foo.o) does not exist, also rescan dependencies if
one of the dependees (e.g. foo.cxx) is older than the already existing
depend.internal file, since this means it can be out of date.
Alex
The Spanish language MFC localization dll changed names from
VS 9 to 10. Use the correct file name ending with "esn.dll"
instead of the now non-existent one ending with "esp.dll"
Also, add the existing, but missing from our rules until now,
Russian language module.
Alphabetize the list while we're at it for easier reading in
the future.
We may want to consider adding some file(GLOB code here to
minimize the risk of missing files added in future versions
of VS.
directory where the project file is located (${CMAKE_BINARY_DIR}), which can
happen e.g. for EXECUTABLE_OUTPUT_PATH and related variables.
Now, it seems this code never worked.
If EXECUTABLE_OUTPUT_PATH was set to point into a subdir of CMAKE_BINARY_DIR,
the code did nothing.
If it pointed directly at CMAKE_BINARY_DIR or some other location, it created
a linked resource. I tested this with Eclipse Europa (3.3) and Juno (4.2), and in this
case both versions of Eclipse complained that this is a bad location for a linked resource.
Alex
It seems that if cmake finds something like the following:
/System/Library/Frameworks/GLUT.framework/Headers
Eclipse doesn't like that and wants to have
/System/Library/Frameworks
instead
Alex
On OSX, the output from gcc looks like this:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
/usr/include/c++/4.2.1/backward
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
The "(framework directory)" part needs to be removed so that Eclipse handles it properly
Alex
Makes it easy to override it, by priming the cache from a release
build script, for example.
Also: correct mistaken @@ variable references with plain ${}
style references so that future readers do not think that it
must be an input to configure_file...
Remove old search paths that aren't needed.
Keep using PATHS instead of HINTS because a Windows machine may have
a different Qt in its PATH and putting QTDIR and the registry entry
ahead of PATH could cause apps to fail when run.
Add options HG_REPOSITORY and HG_TAG to specify an external project
hosted in a Mercurial repository. Teach ExternalProject to clone the
repository and update from it. Extend the ExternalProject test to try a
Mercurial repository when hg is available.
David Cole
Alex Neundorf
Brad King
Kitware Robot
Stephen Kelly
Rolf Eike Beer
Philip Lowman
Peter Kümmel
Clinton Stimpson