For Visual Studio using the Preprocessor Define _SBCS. This behavior
is similar to the way that _UNICODE and _MBCS work already.
Added tests to confirm this behavior.
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.
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.
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
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.
98d2031 Fix BundleUtilities test failure with space in build path.
36d6641 Fix new BundleUtilities test failure on Mac 10.4.x
0d96dec GetPrerequisites: Add test for @rpath support.
880139a GetPrerequisites: Add support for @rpath on Mac OS X.
9a6b102 GetPrerequisites: Add support for @rpath on Mac OS X.
8d83043 AllFindModules test: also check Qt3 modules if Qt4 is not found
e797e7f AllFindModules test: keep complete output
ec631d5 add a test that loops through most Find* modules
This removes some useless checking. The results of these things are never
properly checked so they should not count as testcases. At the end they only
needlessly clutter the output.
6856b4d Merge topic 'link-shared-depend-cycle-issue-12647' into check_symbol_exists
8e1f376 add a test for Check{,CXX}SymbolExists
813eca6 CheckSymbolExists: force the compiler to keep the referenced symbol
0df1942 Detect SGI MIPSpro compiler version with its id
a5e892c Document compiler version macro formats used for detection
d7c6f41 Detect HP compiler version with its id
3dd9fa9 Detect SunPro compiler version with its id
c198730 Detect Watcom compiler version with its id
5899b98 Detect Clang compiler version with its id
b8cfa65 Detect PGI compiler version with its id
6dae666 Detect IBM XL compiler version with its id
4080d55 Detect Borland compiler version with its id
2cc205a Detect Intel compiler version with its id (#11937)
a6d83cc Detect MSVC compiler version with its id
a662855 Detect GNU compiler version with its id (#6251)
fa7141f Add framework to detect compiler version with its id (#12408)
Since commit 183b9509 (Follow all dependencies of shared library private
dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when
following dependent shared libraries. The link interface properties may
form a cycle if set incorrectly by a project. Furthermore, the property
LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand
(though CMake should never generate one). In either case, do not follow
the cycle forever when following the dependent shared library closure.
We only need to add dependency edges to the constraint graph once.
Add "LinkInterfaceLoop" test to cover this case.
Some tests only need to run CMake to configure and generate a build
tree, but not actually perform the build. Add a new "Tests/CMakeOnly"
directory dedicated for this purpose. Add a helper script to drive each
test by creating a fresh build tree and running CMake on it. Add macro
"add_CMakeOnly_test" to help create tests using the script.
53d31c2 complex: Remove unused option to test CMakeLib
c1789e6 complex: Remove test dependence on cmSystemTools
569cee1 complex: Move cmSystemTools::UpperCase test to CMakeLibTests
49d6dd6 complex: Simplify test for single-character exe name
76ac88b complex: Move GeneratedFileStream test to CMakeLibTests
137e597 complex: Remove dynamic loader tests
6337920 complex: Sync Tests/ComplexOneConfig with Tests/Complex
6a75821 complex: Remove ancient unused ComplexRelativePaths test
This test belongs in the CMakeLibTests test driver executable which
correctly links to CMakeLib. Fix incorrect library link order in the
Complex tests exposed by this change.
The two test sources must remain identical. Apply to ComplexOneConfig
the change that commit f578381e (Fix vs2010 project generation error
when HEADER_FILE_ONLY is set, 2010-12-20) made to Complex.
This adds a test that uses two project commands in the same CMakeLists.txt
file. It also adds a fix so that cmake --build will work in that case.
The fix sets the name of the last project command in the top level
CMakeLists.txt in the cache variable CMAKE_PROJECT_NAME. This variable
is used by cmake --build to find the project name.
Since commit 38aab379 (Set CMAKE_<lang>_COMPILER_ID for VS generators,
2011-09-02) the VS IDE generators set the C and C++ compiler id to MSVC
and the Fortran compiler id to Intel. This caused the Fortran test to
fail compatible compiler detection because the if() test
"${CMAKE_C_COMPILER_ID}" MATCHES "MSVC"
is evaluated as the "var MATCHES regex" signature which evaluates the
compiler id "MSVC" as a variable which is defined to 1 which does not
match "MSVC".
Combine tests for non-identical but compatible compiler vendors into a
single regex match whose left hand side will not be defined as a
variable.
In cmComputeLinkDepends we compute the transitive closure of private
shared library dependencies. When a shared library is added to this
closure we must follow all of its dependencies whether they are private
or public. Previously we only followed the private dependencies. Fix
the implementation to follow the public dependencies too. Also extend
the ExportImport test to cover this case.
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
Teach CMakePlatformId.h to construct an "INFO:compiler_version[]" string
literal from macros COMPILER_VERSION_(MAJOR|MINOR|PATCH|TWEAK) to be
defined in CMake(C|CXX)CompilerId.(c|cpp) for each compiler. Provide
conversion macros DEC() and HEX() to decode decimal or hex digits from
integer values. Parse the version out of the compiler id binary along
with the other INFO values already present.
Store the result in variable CMAKE_<LANG>_COMPILER_VERSION in the format
"major[.minor[.patch[.tweak]]]". Save the value persistently in
CMake(C|CXX)Compiler.cmake in the build tree. Document the variable for
internal use since we do not set it everywhere yet.
Report the compiler version on the compiler id result line e.g.
The C compiler identification is GNU 4.5.2
Report CMAKE_(C|CXX)_COMPILER_(ID|VERSION) in SystemInformation test.
ae62a1c Test CMAKE_GNUtoMS option in ExportImport on MinGW and MSys
afb00fe Add CMAKE_GNUtoMS option to convert GNU .dll.a to MS .lib
61e8629 Factor makefile generator link rule lookup into helper function
a603250 Load platform files that need to know the ABI when possible
ecd8414 Fortran: Detect pointer size in gfortran on MinGW
This test will fail to get a proper version number if running on a (e.g.
German) localized system because the regular expression used to match the
Subversion version output does not match. Instead of duplicating code just
remove the local test altogether and use the version that FindSubversion.cmake
already detects.
Since the export() command needs to know the final location of a target
in the build tree we cannot allow properties affecting the location or
name of a target file to be set after the target is passed to export().
Fix a violation of this rule in the SimpleInstall test.
ac2e45d Provide std::ios_base typedef on GCC < 3
28c46ca cmNewLineStyle: Use cmStandardIncludes.h
75e83e9 cmNewLineStyle: Remove trailing comma in enum
be6502c bootstrap: Include cmNewLineStyle in build
a087490 Add NEWLINE_STYLE option to configure_file (#3957)
537020f Tests: Nudge MFC test to pass on VS 6 dashboards (#11213)
51f442e VS11: Update InstallRequiredSystemLibraries.cmake for VS11 (#11213)
d85ab7a Tests: Add environment logging to the MFC test (#11213)
011694c VS10: Use expected values for UseOfMfc (#11213)
a2e6d24 Tests: Fix MFC test to work with VS 10 and later (#11213)
c71f7ab Tests: Avoid MFC test automatically for Watcom WMake builds (#11213)
a42e3f2 Tests: Fix MFC test for old vs6 dashboards (#11213)
b297da6 Tests: Fix MFC test w/ Make-based generators (#11213)
54595e6 Tests: Avoid MFC test automatically for VCExpress builds (#11213)
36b0c43 Tests: Add the MFC test (#11213)
InstallRequiredSystemLibraries does not install any dlls when
used with VS 6 dashboards. Modify the ValidateBuild script to
expect only 1 file when building with VS 6.
Using "-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>" does not work when
<INSTALL_DIR> evaluates to a long enough string. However, using
"-DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>" does work, even with
the longer strings. So: make sure to include the ":PATH" when using
this construct with ExternalProject calls so that they may install
to the proper location on VS 6 builds. All existing calls that match
"CMAKE_INSTALL_PREFIX.*INSTALL_DIR" include the ":PATH" after this
commit.
By the way: https://twitter.com/DLRdave/status/134339505397309440
The mfc app in the test was generated by the VS 7.1 wizard,
and due to changes in VS since then, the values used for WINVER
and _WIN32_WINNT caused compile errors when built with VS 10
or later. Change them to values appropriate for targeting
Windows XP or later when building with VS 10 or later.
See http://msdn.microsoft.com/en-us/library/6sehtctf.aspx
for more info.
The MFC test's mfc1 directory was a "VS-MFC-wizard-generated"
starter MFC app, using VS 7.1 as the generator. There's one define
used in the generated rc file that was not available back in the
VS6 days... Put a conditional define in here based on _MSC_VER
to enable the test app to build on VS6 dashboards.
Build a simple, do-nothing VS 7.1 MFC wizard generated app
with CMake.
Build it two different ways via ExternalProject, one with
CMAKE_MFC_FLAG set to 1 for linking to MFC statically, and
one with CMAKE_MFC_FLAG set to 2 for linking to the shared
MFC dlls.
Validate that the install tree of the static build has only
one *.exe file in it and nothing else. Also validate that the
install tree of the shared library build has multiple files in
it (no less than 3) and that they are only of the expected types
*.exe, *.dll and *.manifest.
This commit does not address the issue reported in #11213,
it merely adds a test that may be used to show that the
bug report is valid. After this commit, the MFC test should
fail on any dashboard machines that have MSVC defined, but
cannot build an MFC app. We can then analyze that failure
data as input to solving the issue.
Provide the ability to configure CTest with settings different from the ones
available in the source tree by checking first if CTestConfig.cmake
exists in the build tree.
The motivation is to allow build system checking out external project to
test and/or package them and submit the associated results to a different
dashboard than the one specified (or not) in the source of the external
project.
For example, the build system of Slicer can checkout, build, test
and package what I will call "extensions". These extensions can be developed
by third parties who can test and submit to their own dashboard / project.
When checked out by Slicer build system, the default dashboard can now be
overwritten by adding a custom CTestConfig.cmake to the build directory.
And if not overwritten, it would avoid to create CTestConfig.cmake within
the source checkout of the extension.
Older svn versions do not have the --depth option for "svn add".
Fortunately we do not need it for versions that old. Look for the
option and use it only when available.
The test adds a subdirectory with
svn add subdir
svn add ... subdir/foo.txt subdir/bar.txt
Subversion 1.7 fails on the second command with
svn: warning: W150002: '.../subdir/foo.txt' is already under version control
svn: warning: W150002: '.../subdir/bar.txt' is already under version control
svn: E200009: Could not add all targets because some targets don't exist
because it considers adding an already-versioned file to be an error.
Avoid the problem by using
svn add --depth=empty subdir
to add the subdirectory without the files it contains.
Aaron C. Meadows
David Cole
Rolf Eike Beer
Brad King
Bill Hoffman
Clinton Stimpson
Alex Neundorf
Peter Kuemmel
Stephen Kelly
Eric NOULARD
Jean-Christophe Fillion-Robin