The Mac linker defines flag -headerpad_max_install_names but not all
front-ends recognize the flag and pass it through (many did in the past,
such as the Apple port of GCC). Use the -Wl, option prefix to tell
front-ends to pass it through without trying to interpret it.
One of Cygwin's goals is to build projects using the POSIX API with no
Windows awareness. Many CMake-built projects have been written to test
for UNIX and WIN32 but not CYGWIN. The preferred behavior under Cygwin
in such projects is to take the UNIX path but not the WIN32 path.
Unfortunately this change is BACKWARDS INCOMPATIBLE for Cygwin-aware
CMake projects! Some projects that previously built under Cygwin and
are Cygwin-aware when they test for WIN32 may now behave differently.
Eventually these projects will need to be updated, but to help users
build them in the meantime we print a warning about the change in
behavior. Furthermore, one may set CMAKE_LEGACY_CYGWIN_WIN32 to request
old behavior during the transition.
Normally we avoid backwards incompatible changes, but we make an
exception in this case for a few reasons:
(1) This behavior is preferred by Cygwin's design goals.
(2) A warning provides a clear path forward for everyone who may see
incompatible behavior, and CMAKE_LEGACY_CYGWIN_WIN32 provides a
compatibility option. The warning and compatibility option both
disappear when the minimum required version of CMake in a project is
sufficiently new, so this issue will simply go away over time as
projects are updated to account for the change.
(3) The fixes required to update projects are fairly insignificant.
Furthermore, the Cygwin distribution has no releases itself so project
versions that predate said fixes tend to be difficult to build anyway.
(4) This change enables many CMake-built projects that did not
previously build under Cygwin to work out-of-the-box. From bug #10122:
"I have built over 120 different source packages with (my patched)
CMake, including most of KDE4, and have found that NOT defining
WIN32 on Cygwin is much more accurate." -- Yaakov Selkowitz
A fully compatible change would require patches on top of these project
releases for Cygwin even though they otherwise need not be aware of it.
(5) Yaakov has been maintaining a fork of CMake with this change for the
Cygwin Ports distribution. It works well in practice. By accepting the
change in upstream CMake we avoid confusion between the versions.
CMake itself builds without WIN32 defined on Cygwin. Simply disable
CMAKE_LEGACY_CYGWIN_WIN32 explicitly in our own CMakeLists.txt file.
09d1c10 FortranCInterface: Recognize NAG Fortran module symbols
af2ad90 Add NAG Fortran compiler information files
24cc3d4 Recognize the NAG Fortran compiler
83892c4 Allow Fortran platform files to set empty values
fe3f878 Detect object files in implicit link information
Use "int main(void)" instead of just "int main()" so that compiling with
"gcc -Werror=strict-prototypes" works. Test this check using the flags
"-Werror -Wstrict-prototypes" to work with old GCC versions.
Since commit aff31479 (Modernize GNU compiler info on Windows,
2009-12-02) the file Modules/Platform/Windows-g++.cmake has been unused.
It just includes the non-existent Modules/Platform/Windows-gcc.cmake so
remove it outright.
This moves Intel compiler info on Windows into new-style modules
Platform/Windows-Intel-<lang>.cmake
using language-independent helper module
Platform/Windows-Intel.cmake
to define macros consolidating the information.
Commit 4430bccc (Change the way 32/64 bit compiles are detected with
MSVC and intel, 2009-11-19) added detection of the target processor to C
and CXX language builds with MS and Intel tools. Do the same for Intel
Fortran for Windows (ifort). Use /machine:<arch> to link executables.
3bc828d Fixed bug where last entry would be lost.
b316087 Escape file write expansion, and build up lists.
68cd3fe Added CMAKE_CACHE_ARGS to ExternalProject.
27ee50a Add ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT as a ADVANCED cache variable (#9631)
50d21d4 Add cache var CMAKE_ECLIPSE_MAKE_ARGUMENTS when using the Eclipse generator
This variable can be set to command line arguments which will be passed
to make when eclipse invokes make, e.g. you can enter "-j8" to get
8 parallel builds (#9930)
Alex
Escaped the @var@ in the file writes - this was being expanded at file
write and so not causing a reconfigure at the right time. I also took
care of build up lists of lists in the variables, especially important
for things like MPI_EXTRA_LIBRARY. Added some error checking, and use
the tmp_dir for initial cache file.
On Windows the limit for command line arguments is 8192 characters, and
this was limiting longer paths with some of our more nested projects
such as Library. Placing the -D arguments into CMAKE_CACHE_ARGS will
write out an initial cache file, that will be passed to CMake with a -C
argument as the initial cache.
By forcing the cache variables we preserve the existing behavior with
-D, to change the values of cache variables in our inner projects.
On Linux the NAG Fortran compiler uses gcc under the hood to link. Use
"-Wl,-v" to pass "-v" to the underlying gcc compiler to get verbose link
output. Detect the NAG Fortran directory (using -dryrun) and then honor
object files in the directory referenced in the implicit link line.
Pass real linker options with "-Wl,-Xlinker,". The -Wl, gets through
the NAG front-end and the -Xlinker gets through the gcc front-end.
The Numerical Algorithms Group (NAG) Fortran compiler does not document
a preprocessor macro to identify it. Check for identifying output using
the -V option.
Teach CMakeFortranInformation to use default flags only for variables
that have not been set at all, rather then not set or empty. This will
allow platform or compiler-specific information files to set empty
values without getting the defaults.
The NAG Fortran compiler implicitly passes object files by full path to
the linker. Teach CMakeParseImplicitLinkInfo to parse object files that
match some tool-specific regular expression.
FindTCL.cmake switched variables in the FIND_LIBRARY invocation. The
FIND_LIBRARY() statement for TCL used the TK variables and vice versa.
This patch reverses that into the right usage.
Closes debian issue 600245.
Also, improve the documentation of the fixup_bundle and fixup_bundle_item
functions to clarify that plugin type "libs" need to be copied into
the bundle *before* calling fixup_bundle.
Commit e93a4b4d34 changed the way that
the libs parameter to fixup_bundle is interpreted. Before the commit,
the libs were copied into the bundle first and then fixed up. After
the commit, the copy was skipped, assuming the libs were in the bundle
in the first place, and then the fixups occurred as before.
However, before the commit, it was possible to name a lib from outside
the bundle, and have it copied in and then fixed up. Its resolved
embedded name was always inside the bundle before. After, its resolved
embedded name was just the same as its resolved name, which is in its
original location, and not necessarily inside the bundle.
This manifested itself as a problem with the ParaView call to
fixup_bundle and its many plugins. Previously, ParaView had simply
passed in the list of plugin file names as they existed in the build
tree, and left the copying into the bundle up to the fixup_bundle
function. When built with CMake 2.8.3 (the first version to contain
the above named commit) the fixup_bundle call would inadventently
fixup libraries in the build tree, not libraries that were in the
bundle. Furthermore, the plugins would not be in the final bundle.
This points out the fact that the fix for the bugs made by the above
commit was a backwards-incompatible change in behavior.
This commit makes it an error to try to fixup an item that is not
already inside the bundle to make the change in behavior apparent
to folks who were depending on the prior copy-in behavior: now,
they should get an error, and hopefully, reading the new and
improved documentation, should be able to resolve it in their
projects by adding code to install or copy in such libraries prior
to calling fixup_bundle.
Whew.
e0b6016 Some more fixes for nasm support, from Etienne (#10069)
d25c2eb Use CMAKE_ASM_NASM_FLAGS for nasm instead of FLAGS
e614e9b Add support for yasm, a nasm compatible assembler
79dd9be We already have 2010, fix copyright year.
ffeca06 Add missing copyright headers
7b337ac Improve misleading comments.
e1fc9b9 Add support for nasm assembler, patch by Peter Collingbourne (see #10069)
Use the Config mode of find_package to search for ITKConfig. This makes
FindITK a thin-wrapper around a standard find_package, bringing benefits
like searching lib64 paths when appropriate. This does for FindITK what
commit 2c1a01dc (Modernize FindVTK module, 2009-10-07) did for FindVTK.
The Mac linker defines -headerpad_max_install_names and the GCC
front-end passes this flag through. The PGI compiler does not know
about this flag, so we must use -Wl,-headerpad_max_install_names to pass
it to the linker instead.
CMakeDetermineASMCompiler.cmake relied on that somebody else (usually
during enabling C or CXX) already included that file, and broke if that
was not the case.
Thanks to Louis for the patch
Alex
The Cray Fortran compiler needs "-em" to enable module output and also
"-J." to place the .mod files in the current working directory (instead
of next to the .o file).
Previously FindPerlLibs did not work with the Mac stock Perl because it
includes patches. From "perl -V":
Locally applied patches:
/Library/Perl/Updates/<version> comes before system perl directories
installprivlib and installarchlib points to the Updates directory
Adjust paths accordingly.
48e80eb Fixes to GetPrerequisites for cygwin
bee4802 Append the gp_tool path to the system PATH using native slashes.
8e550ba Remove unecessary TO_CMAKE_PATH for gp_cmd_dir.
1684198 Switch to CMAKE_PATH when doing PATH comparisons on Windows.
be94c49 Fixed appending PATH to dumpbin tool from growing without bounds.
Fix IF(WIN32) guards check for cygwin. Fix checking if the depenency is in a system location to use cygwin style paths on cygwin. Also change GetPrerequisites to switch gp_tool to tools that are very unlikely to be found, ie. dumpbin on Apple and otool on Windows/Unix.
Users PATH may contain elements that end with backslash. This will escape the semicolon when iterating resulting in mismatches.
Fix indentation.
Fix whitespace
This fixes bugs #0011355 and 0008342.
The merged patch is a contribution from Michael Lasmanis and Petri Hodju
with some extra documentation added by the merger.
IF(... MATCHES ...) used for comparing directories chokes especially in the case of C:\Program Files (x86)\<blah> because of regex pattern matching. Switched this to use STREQUAL in a loop instead.
Fixed parallel build for projects using generators that have the
CMAKE_EXTRA_GENERATOR as well as CMAKE_GENERATOR. Thanks to Bill Hoffman
for helping me to track this one down, I missed parallel builds.
There is no need to introduce this extra variable as FindBoost
can simply rely on if Boost_USE_STATIC_RUNTIME is defined
or not to disable the old searching behavior for static runtime
libraries on WIN32.
On a Win32 system with a German version of SilkSVN I couldn't run CMake
again on the working copy as the cache is displayed as corrupted. The
cause is that the regular expression to find the version number will not
match and put everything from the "svn --version" output into the cache,
which contains umlauts and other funny characters.
Fix the regexp to not only match " version " but also " Version " as
it's in the German output. I have no idea what will happen on a French
or Japanese system. This should be easy to test as it happens also on a
German Linux system.
b935f00 Close ENDFUNCTION() properly with the same name as FUNCTION()
07bca48 Set a default DESCRIPTION if none is given for ALL mode of feature_summary()
d5b2915 APPEND and not-APPEND mode of feature_summary() were swapped
In each CMake<lang>Information.cmake file we use an _INCLUDED_FILE
variable to track whether a compiler information file has been loaded.
Reset this variable for each language.
This fixes Fortran under VS generators with the Intel plugin.
Previously the variable would be left set true from C and C++ and then
Fortran would not load old-style files like Platform/Windows-ifort.
If a Qt installation is in CMAKE_PREFIX_PATH and a
QT_QMAKE_EXECUTABLE points to a qmake for a different Qt installation,
prefer finding libs in the latter Qt installation.
Use a separate variable to pass to the BUILD_COMMAND call
and then use set(CACHE) to transfer that to MAKECOMMAND.
That way, if MAKECOMMAND is in the cache already, it is
left untouched. Fixes regression introduced in commit
0b38bb4c with the fix for bug #2336.
Thanks to Evgeniy P for the patch.