2008-02-07 19:43:20 +03:00
|
|
|
# This file is configured at cmake time, and loaded at cpack time.
|
|
|
|
|
# To pass variables to cpack from cmake, they must be configured
|
|
|
|
|
# in this file.
|
|
|
|
|
|
2007-10-31 06:02:43 +03:00
|
|
|
if(CPACK_GENERATOR MATCHES "NSIS")
|
Add CPACK_NSIS_INSTALL_ROOT for CMake's own installer (#9148)
Problem with CMake 2.8.4-rc1: when you launch the NSIS exe installer
on Windows, the default install path shown to the end user is, at first,
"\CMake 2.8".
This problem started occurring when configuring CMake itself with an
older CMake, after adding CPACK_NSIS_INSTALL_ROOT to fix issue 9148.
So... it's a regression from 2.8.3.
I forgot (again) that when you add a new CPack variable, you must
add it to CMake's CMakeCPack.cmake file or else it is empty when
configured with an older CMake. And on Windows, without a bootstrap
build available, the releases are always configured with an older
version of CMake. This may be the last time this has bitten me,
though, because it is now burned into my brain that problems with
CMake's installer itself are inevitably associated with adding new
CPack variables.
In addition to adding a definition for CPACK_NSIS_INSTALL_ROOT,
I've gone ahead and made it differ for the 32- and 64-bit builds
of CMake to give the end user the expected default value for the
Program Files folder for each one.
And, since I was adding a new 32/64 differentiator anyhow, I made
the "NSIS package name" and "installer registry key base" different
for 64-bit builds, too, by appending " (Win64)" to each one.
These address the concerns mentioned in 9148's related issue:
http://public.kitware.com/Bug/view.php?id=9094 (at least as far
as CMake's installer is concerned). 9094 could still use a good
general fix for all projects, though, and remains open for now.
2011-01-13 23:36:45 +03:00
|
|
|
SET(CPACK_NSIS_INSTALL_ROOT "@CPACK_NSIS_INSTALL_ROOT@")
|
|
|
|
|
|
2007-10-31 06:02:43 +03:00
|
|
|
# set the install/unistall icon used for the installer itself
|
Add CPACK_NSIS_INSTALL_ROOT for CMake's own installer (#9148)
Problem with CMake 2.8.4-rc1: when you launch the NSIS exe installer
on Windows, the default install path shown to the end user is, at first,
"\CMake 2.8".
This problem started occurring when configuring CMake itself with an
older CMake, after adding CPACK_NSIS_INSTALL_ROOT to fix issue 9148.
So... it's a regression from 2.8.3.
I forgot (again) that when you add a new CPack variable, you must
add it to CMake's CMakeCPack.cmake file or else it is empty when
configured with an older CMake. And on Windows, without a bootstrap
build available, the releases are always configured with an older
version of CMake. This may be the last time this has bitten me,
though, because it is now burned into my brain that problems with
CMake's installer itself are inevitably associated with adding new
CPack variables.
In addition to adding a definition for CPACK_NSIS_INSTALL_ROOT,
I've gone ahead and made it differ for the 32- and 64-bit builds
of CMake to give the end user the expected default value for the
Program Files folder for each one.
And, since I was adding a new 32/64 differentiator anyhow, I made
the "NSIS package name" and "installer registry key base" different
for 64-bit builds, too, by appending " (Win64)" to each one.
These address the concerns mentioned in 9148's related issue:
http://public.kitware.com/Bug/view.php?id=9094 (at least as far
as CMake's installer is concerned). 9094 could still use a good
general fix for all projects, though, and remains open for now.
2011-01-13 23:36:45 +03:00
|
|
|
# There is a bug in NSI that does not handle full unix paths properly.
|
2007-10-31 06:02:43 +03:00
|
|
|
SET(CPACK_NSIS_MUI_ICON "@CMake_SOURCE_DIR@/Utilities/Release\\CMakeLogo.ico")
|
|
|
|
|
SET(CPACK_NSIS_MUI_UNIICON "@CMake_SOURCE_DIR@/Utilities/Release\\CMakeLogo.ico")
|
|
|
|
|
# set the package header icon for MUI
|
|
|
|
|
SET(CPACK_PACKAGE_ICON "@CMake_SOURCE_DIR@/Utilities/Release\\CMakeInstall.bmp")
|
|
|
|
|
# tell cpack to create links to the doc files
|
|
|
|
|
SET(CPACK_NSIS_MENU_LINKS
|
2009-02-14 05:51:46 +03:00
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake-gui.html" "cmake-gui Help"
|
2007-10-31 06:02:43 +03:00
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html" "CMake Help"
|
|
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake-properties.html"
|
|
|
|
|
"CMake Properties and Variables Help"
|
|
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/ctest.html" "CTest Help"
|
|
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake-modules.html" "CMake Modules Help"
|
|
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake-commands.html" "CMake Commands Help"
|
|
|
|
|
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cpack.html" "CPack Help"
|
|
|
|
|
"http://www.cmake.org" "CMake Web Site"
|
|
|
|
|
)
|
Add CPACK_NSIS_INSTALL_ROOT for CMake's own installer (#9148)
Problem with CMake 2.8.4-rc1: when you launch the NSIS exe installer
on Windows, the default install path shown to the end user is, at first,
"\CMake 2.8".
This problem started occurring when configuring CMake itself with an
older CMake, after adding CPACK_NSIS_INSTALL_ROOT to fix issue 9148.
So... it's a regression from 2.8.3.
I forgot (again) that when you add a new CPack variable, you must
add it to CMake's CMakeCPack.cmake file or else it is empty when
configured with an older CMake. And on Windows, without a bootstrap
build available, the releases are always configured with an older
version of CMake. This may be the last time this has bitten me,
though, because it is now burned into my brain that problems with
CMake's installer itself are inevitably associated with adding new
CPack variables.
In addition to adding a definition for CPACK_NSIS_INSTALL_ROOT,
I've gone ahead and made it differ for the 32- and 64-bit builds
of CMake to give the end user the expected default value for the
Program Files folder for each one.
And, since I was adding a new 32/64 differentiator anyhow, I made
the "NSIS package name" and "installer registry key base" different
for 64-bit builds, too, by appending " (Win64)" to each one.
These address the concerns mentioned in 9148's related issue:
http://public.kitware.com/Bug/view.php?id=9094 (at least as far
as CMake's installer is concerned). 9094 could still use a good
general fix for all projects, though, and remains open for now.
2011-01-13 23:36:45 +03:00
|
|
|
# Use the icon from cmake-gui for add-remove programs
|
2009-09-25 19:26:28 +04:00
|
|
|
SET(CPACK_NSIS_INSTALLED_ICON_NAME "bin\\cmake-gui.exe")
|
|
|
|
|
|
Add CPACK_NSIS_INSTALL_ROOT for CMake's own installer (#9148)
Problem with CMake 2.8.4-rc1: when you launch the NSIS exe installer
on Windows, the default install path shown to the end user is, at first,
"\CMake 2.8".
This problem started occurring when configuring CMake itself with an
older CMake, after adding CPACK_NSIS_INSTALL_ROOT to fix issue 9148.
So... it's a regression from 2.8.3.
I forgot (again) that when you add a new CPack variable, you must
add it to CMake's CMakeCPack.cmake file or else it is empty when
configured with an older CMake. And on Windows, without a bootstrap
build available, the releases are always configured with an older
version of CMake. This may be the last time this has bitten me,
though, because it is now burned into my brain that problems with
CMake's installer itself are inevitably associated with adding new
CPack variables.
In addition to adding a definition for CPACK_NSIS_INSTALL_ROOT,
I've gone ahead and made it differ for the 32- and 64-bit builds
of CMake to give the end user the expected default value for the
Program Files folder for each one.
And, since I was adding a new 32/64 differentiator anyhow, I made
the "NSIS package name" and "installer registry key base" different
for 64-bit builds, too, by appending " (Win64)" to each one.
These address the concerns mentioned in 9148's related issue:
http://public.kitware.com/Bug/view.php?id=9094 (at least as far
as CMake's installer is concerned). 9094 could still use a good
general fix for all projects, though, and remains open for now.
2011-01-13 23:36:45 +03:00
|
|
|
SET(CPACK_NSIS_PACKAGE_NAME "@CPACK_NSIS_PACKAGE_NAME@")
|
|
|
|
|
SET(CPACK_NSIS_DISPLAY_NAME "@CPACK_NSIS_PACKAGE_NAME@, a cross-platform, open-source build system")
|
2009-07-20 20:08:34 +04:00
|
|
|
SET(CPACK_NSIS_HELP_LINK "http://www.cmake.org")
|
|
|
|
|
SET(CPACK_NSIS_URL_INFO_ABOUT "http://www.kitware.com")
|
2007-10-31 06:02:43 +03:00
|
|
|
SET(CPACK_NSIS_CONTACT @CPACK_PACKAGE_CONTACT@)
|
|
|
|
|
SET(CPACK_NSIS_MODIFY_PATH ON)
|
|
|
|
|
endif(CPACK_GENERATOR MATCHES "NSIS")
|
2009-07-20 20:08:34 +04:00
|
|
|
|
2008-03-13 04:54:27 +03:00
|
|
|
# include the cpack options for qt dialog if they exisit
|
|
|
|
|
# they might not if qt was not enabled for the build
|
|
|
|
|
INCLUDE("@QT_DIALOG_CPACK_OPTIONS_FILE@" OPTIONAL)
|
2007-10-31 19:55:04 +03:00
|
|
|
|
|
|
|
|
if(CPACK_GENERATOR MATCHES "CygwinSource")
|
|
|
|
|
# when packaging source make sure the .build directory is not included
|
|
|
|
|
SET(CPACK_SOURCE_IGNORE_FILES
|
|
|
|
|
"/CVS/" "/\\.build/" "/\\.svn/" "\\.swp$" "\\.#" "/#" "~$")
|
|
|
|
|
endif(CPACK_GENERATOR MATCHES "CygwinSource")
|
2007-12-27 00:57:13 +03:00
|
|
|
|
|
|
|
|
if("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
|
2008-02-18 23:50:37 +03:00
|
|
|
if(CMAKE_PACKAGE_QTGUI)
|
|
|
|
|
set(CPACK_PACKAGE_DEFAULT_LOCATION "/Applications")
|
|
|
|
|
else(CMAKE_PACKAGE_QTGUI)
|
|
|
|
|
set(CPACK_PACKAGE_DEFAULT_LOCATION "/usr")
|
|
|
|
|
endif(CMAKE_PACKAGE_QTGUI)
|
2007-12-27 00:57:13 +03:00
|
|
|
endif("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
|
