We do not yet support "make install" in the external project case.
Document this explicitly in the interface. Require the caller to use an
option to "disable" the unsupported behavior. This will allow us to add
the behavior by default in the future without clobbering existing
projects that handle the installation themselves.
cmake_add_fortran_directory uses imported targets when using the
mingw fortran compiler. This change makes those targets global
in scope so they act just like the real targets that exist when
a fortran compiler exists and regular add_subdirectory is used.
The SunPro compiler does not add the fortran runtime library when
creating a shared fortran library. Link to the SunPro Fortran runtime
libraries explicitly.
Verify that MINGW_GFORTRAN not only points to a MinGW gfortran but also
one that compiles for the target architecture. This prevents using a
32-bit gfortran in a 64-bit MSVC build.
In the find_program(MINGW_GFORTRAN) call use the PATHS option for
hard-coded guesses instead of HINTS. This allows the user environment
to override the guesses and corrects usage of the command options.
Fix the implementation to allow full paths with spaces. Change the
interpretation of relative paths to be with respect to the current binary
directory. This matches the convention used in ExternalProject. Test
both full and relative paths in the VSGNUFortran test.
This patch adds a new module that allows for easy integration of MinGW
gfortran and the Visual Studio compiler. It is done in a function called
cmake_add_fortran_subdirectory. The patch also includes a test for this
feature.
Define a "check_language(<lang>)" macro to test whether <lang> can be
enabled. Cache the result in CMAKE_<lang>_COMPILER. Add a test case
covering expected results.
5d18851 CPackArchive restore default behavior and provide new variable.
3cab24a CPack Add top level directory in component install for Archive Generators
ed1b126 CMakeOnly.AllFindModules: require version for some modules
2dee929 CMakeOnly.AllFindModules: suppress two modules from testing
3c4b4ff CMakeOnly.AllFindModules: always check FindQt
9d72b25 CMakeOnly.AllFindModules: clean up the Qt3/Qt4 code
When configuring or generating the 'ng' of the end of the second line
is not cleared. This patch fixes this.
The problem was introduced by commit fd632195 (ccmake: Align 'g' and 'q'
key instructions, 2011-01-07) which adjusted the length of lines that
need clearing.
The approach taken by commit 8704525f (Reject directory names containing
'=', 2011-01-14) was perhaps too heavy-handed for avoiding the obscure
cases when '=' in the path fails due to limitations of Make syntax.
Only two CMake tests:
LinkDirectory
OutOfSource
fail when the path contains '=' and they cover obscure cases. Instead
of rejecting such paths outright just warn when the problem may occur.
If CXX or Fortran is enabled before C then the values of
CMAKE_SHARED_MODULE_C_FLAGS
CMAKE_SHARED_MODULE_CREATE_C_FLAGS
may not be available. On platforms where MODULE library (plugin) creation
is the same as SHARED library creation initialize the MODULE creation
flags from the SHARED creation flags of the matching language instead of
assuming that C has been enabled first.
Teach the COnly and CxxOnly tests to build MODULE libraries. The latter
covers this specific case.
An implementation ;-separated list parsing was added by commit a1f976ce
(VS: Add support for three new project properties, 2011-11-23) and again
by commit 9e01aefd (VS: Add support for WinRT project properties,
2012-02-03). Refactor both instances to use ExpandListArgument.
Bill Hoffman
Artur Kedzierski
Brad King
KWSys Robot
Clinton Stimpson
Rolf Eike Beer
David Cole
Nicolas Despres
Eric NOULARD
Peter Collingbourne