Do not use file(TO_NATIVE_PATH) to compute the value to store in the
registry. It is meant for constructing values to be put in shells.
Since find_package() can use the value with CMake-normalized slashes do
not bother with any conversion.
Teach the FindPackagTest to try creating the appropriate HKLM system
package registry value. If it works then add a test to verify that
find_package() reads it as expected. Then delete the value to cleanup.
The system package registry is under HKEY_LOCAL_MACHINE\SOFTWARE which
has separate views for 32-bit and 64-bit applications. Look in both
views, but prefer the architecture matching the build target platform.
Generalize the "user package registry" created by commit ed0650f6 (Teach
find_package to search a "package registry", 2009-09-01). Define a
corresponding "system" registry key under HKEY_LOCAL_MACHINE. This
gives package installers a place to create a registry value that points
at the right location for find_package() to locate the package.
Delete only REG_SZ entries that are specifically detected to point to
invalid paths. This will allow future versions to add other value types
for different purposes.
This file has not been used in KWSys since commit "Moved test for large
file support into kwsysPlatformCxxTests.cxx", 2006-08-25. CMake 2.6.0
and above come with a copy of this module anyway, and KWSys has required
CMake 2.6.3 since commit "KWSys: Require at least CMake 2.6.3",
2011-03-01.
234bae7 VS10: Fix exit code of custom commands with setlocal/endlocal (#11938)
b98fdd5 VS: Use setlocal/endlocal only in VS 10 custom commands
06fcbc4 VS10: Fix working directory of consecutive custom commands (#11938)
Which adds --non-interactive and --trust-server-cert to the svn
checkout and update command lines. This allows ExternalProject
clients to pull from an https:// based svn server even though
the server may not have a valid or trusted certificate.
Caveat emptor: I would NOT recommend using this except as a
short-term work-around. Rather, the server should have a valid,
trusted certificate, or the client should be using "http" instead
of "https".
Use the pattern
setlocal
...
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
in custom commands to preserve the %errorlevel% from inside the
setlocal/endlocal block.
The setlocal/endlocal and errorlevel pattern added by commit 06fcbc47
(VS10: Fix working directory of consecutive custom commands, 2011-04-08)
does not work well in VS 7.1. Restore the original behavior for VS
versions that do not need the new behavior.
Copy the files specified in CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA to the right
directory when packaging components. This fixes#12061.
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
The parent commit assumed that "cd /d" would work in all Windows shells.
While all modern versions of windows have shells that support it, the
shells used by NMake and Borland make do not. Borland make does not
seem to even support changing drive letters with "d:". Just revert the
feature for all make tools except MinGW where the shell is known to
support this feature.
Teach cmLocalUnixMakefileGenerator3::CreateCDCommand to change working
directories for make tools using a Windows shell using "cd /d" instead
of just "cd". This tells the shell to change the current drive letter
as well as the working directory on that drive.
Commit abaa0267 (When the working directory for a custom command is on
another drive..., 2007-12-17) fixed the same problem for VS IDE
generators as reported by issue #6150.
The VS 10 msbuild tool uses a single command shell to invoke all the
custom command scripts in a project. Isolate the environment and
working directory of custom commands using setlocal/endlocal. The
form of each command is
set errlev=
setlocal
cd c:\work\dir
if %errorlevel% neq 0 goto :cmEnd
c:
if %errorlevel% neq 0 goto :cmEnd
command1 ...
if %errorlevel% neq 0 goto :cmEnd
...
commandN ...
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & set errlev=%errorlevel%
if %errlev% neq 0 goto :VCEnd
so that all changes to the environment and working directory are
isolated within the script and the return code is preserved.
This commit fixes BUG: 0011782. UseSWIG would be using the same variable
to declare module information. The problem would only be noticed in parallel builds
Fix this variable declaration by properly resetting it.
This commit fixes BUG: 0011215 by properly expanding $(OutDir)
Instead of creating the output directory using file(MAKE_DIRECTORY)
we use cmake -E to create the directory at execution time
This commit fixes BUG: 0004147 it directly uses swig executable
to compute a list of dependencies directly from the .i files
to make sure to rebuild the swig module any of its direct dep.
is touched
The XL toolchain supports shared object files stored in archives. Since
CMake lists libraries on link lines by full path it is common for a
shared library link line to contain the path to an archive file.
When linking a shared library the compiler front-end by default runs
CreateExportList to construct the list of symbols to be exported.
Unfortunately it passes all files found on the command line to the tool
so archive and library files get processed along with the object files.
The tool returns a list of all symbols in all objects, archives, and
libraries on the command line. This causes the linker to copy every
object file out of every archive into the shared library whether they
are dependencies of the original object files or not.
Work around this problem by running CreateExportList ourselves with just
the original object files intended for inclusion in the shared library.
Then pass the list it produces on the link line to prevent the compiler
front-end from constructing its own. This tells the linker to export
only the symbols provided by the original source files of the shared
library.
Eric NOULARD
KWSys Robot
Brad King
David Cole
Martin Konrad
Mathieu Malaterre