MUI_FINISHPAGE_RUN is frequently used with NSIS and provides a checkbox
on the finish page of an installer which specifies whether the specified
executable should be run when the installer exits. This commit adds support
for this setting in CPack.
NSIS installers default to assuming the executables exist in a
directory named "bin" under the installation directory. As this
isn't usual for Windows programs, the addition of this variable
allows the customization of this directory and links still to be
created correctly.
971692c Build enable_language command during bootstrap
960ace1 Add testing for windows resources for mingw/msys/cygwin and remove for watcom.
060d6e8 Add support for windres to cygwin.
b2f308c Add support for windows resources with mingw/msys.
Since commit 70c2dc8a (Make compiler id detection more robust,
2008-03-10) we store compiler identification strings in test binaries
using the form
char* info = "info";
Use the const-correct
char const* info = "info";
form instead. This allows the C++ compiler identification to work with
"-Werror -Wall" or equivalent flags if the compiler would warn about
const-to-non-const conversion.
The TI DSP compiler predefines "__TI_COMPILER_VERSION__". Use this to
identify the C and C++ compilers. For assembler language the C compiler
executable is used:
$ cl6x -h
TMS320C6x C/C++ Compiler v6.1.11
Tools Copyright (c) 1996-2009 Texas Instruments Incorporated
Use this command-line option and output to recognize the assembler.
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
Mike McQuaid
Brad King
Bill Hoffman
Wojciech Migda
Philip Lowman
Alexey Ozeritsky
Clinton Stimpson
Eric NOULARD
Alex Neundorf