Add "private/internal-use-only" function _ep_get_step_stampfile
to get the name of the stamp file for a given step.
The functionality provided by this commit should be identical
to its parent commit.
In the case of git, only track the repository in the
repository info dependency tracking file. Not the tag.
The download step should only re-run if the repository changes.
The download step should NOT re-run if the tag changes.
The update step is an 'always' re-running step, and so should
already re-run, unless it's been eliminated by use of
UPDATE_COMMAND ""
Use of the deprecated option with Intel 2011 produces
icl: command line remark #10010: option '/GX' is deprecated and will
be removed in a future release. See '/help deprecated'
so use its replacement option which has been supported for several
older versions anyway.
If CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL is set to ON the NSIS installer will look for a previous installed version and ask the user about uninstall.
Commit f67139ae added running a verify script in between running
the download and extract scripts. Since then, it has always been
missing the COMMAND keyword added in this commit.
It worked anyway (semi-accidentally) by running a command line like:
cmake -P script1.cmake cmake -P script2.cmake
CMake, when running -P scripts on the command line, runs them in order,
and apparently ignores spurious arguments in between (the middle "cmake"
in the above example) and so, all appeared to work as intended.
This commit adds the missing keyword and the commands that run are
now two separate sequential cmake invocations like:
cmake -P script1.cmake
cmake -P script2.cmake
...which was the original intent of commit f67139ae
Allows custom NSIS commands to run prior to any installation
actions. Projects that need to run an uninstaller first,
especially one from a non-NSIS previous revision of a project
that is NOW using CPack and NSIS, may do so by putting custom
NSIS commands into this variable.
Inspired-by: David Golub
As Dave Abrahams pointed out CMAKE_CURRENT_SOURCE_PATH is wrong, it's of
course CMAKE_CURRENT_SOURCE_DIR.
Also wrap the path in quotes so the example would even work if the source path
has spaces.
6190415 OS X: Mark find_program results as advanced
d9edf46 OS X: Use correct extra path when searching for applicaton bundles (#13066)
98b9a7f OS X: Use OSX_DEVELOPER_ROOT for app search path (#13066)
Since commit 44d007b6 (CheckIncludeFiles: fix status output, 2012-02-01)
check_include_files reports the list of files tested instead of the name
of the variable storing the result. Some projects incrementally test
and concatenate very long lists leading to long messages that do not
provide much information. Users report confusion especially when the
lines wrap.
For lists of more than two files produce messages of the format
Looing for N include files first.h, ..., last.h
where N is the list length and "..." is literal. Leave the log file
entries and cache entry description unchanged as they should have the
full detail of the check performed.
The parent commit added a search path relative to OSX_DEVELOPER_ROOT.
But with Xcode 4.3 the nested Applications folder is in a different
relative location compared to that root. This commit makes the intent
of the previous commit work with older and newer Xcode directory layouts.
Furthermore, it only adds paths that exist to the search path.
Starting with Python3, standard Python installs may have additional ABI
flags attached to include directories and library names. As of 3.2, the
following flags are in the configure file:
d -> --with-debug
m -> --with-pymalloc
u -> --with-wide-unicode
Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python
will ensure that the possible flags always show up in a stable order.
The 'd' flag is ignored since the debug library is considered separate.
There is still the problem where ABI flags cannot be specified in
find_package since the letters confuse the version comparator.
If PYTHON_INCLUDE_PATH is put into the cache, then it will always
override whatever might be found and PYTHON_INCLUDE_DIR is never given a
chance to find something different. It being marked as INTERNAL also
means that it cannot be changed without editing CMakeCache.txt directly.
Basically, the scenario is that if the Python version is changed, then
deleting PYTHON_INCLUDE_DIR doesn't work because any cached
PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any
build tree using a previous version will still need either manual
removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the
future changing the Python version can be accomplished by deleting
PYTHON_INCLUDE_DIR and reconfiguring with the new version.
9b32475 automoc: add define to test which caused bug #130182066511 automoc: fix#13018, proper cmake escaping to avoid false rebuilds
c652812 make cmLocalGenerator::EscapeForCMake() static
The variables stored in the AutomocInfo.cmake file were not properly
escaped, so when reading them back they could turn into lists, if they
contained double quotes initially.
This patch fixes this by using cmLocalGenerator::EscapeForCMake() to
escape the variables properly.
Alex
Since commit 4693cf84 (Xcode: Detect new default locations of Xcode 4.3
bits and pieces) Darwin.cmake detects the developer application
directory instead of hard-coding /Developer. Replace the hard-coded
path in CMAKE_SYSTEM_APPBUNDLE_PATH using the computed result.
Patch by Amine Khaldi!
Also, start using the -MT flag to set a target name for depfiles.
This works around a bug observed in distcc, as explained in the
comment. Based on a patch by Alexander Usov.
This patch uses get_filename_component(REALPATH) so symlinks in the path
to Eclipse are resolved, which makes the version detection work in such cases.
Alex
Use the CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES to look for libraries
that are in the -showme output from mpi<lang> programs. This is because
some libraries reported by -showme are found there, and FindMPI will
fail if they are not found.
0f4dfa6 CPack: Use real path to PackageMaker to find its version file (#12621)
4693cf8 Xcode: Detect new default locations of Xcode 4.3 bits and pieces (#12621)
As discussed on cmake-developers, this patch adds a macro
check_required_components() to the file configured via
configure_package_config_file(), so for proper handling
of components in Config.cmake files users can simply call
check_required_components(PackageName)
and this will do the right thing.
Alex
if the HANDLE_COMPONENTS is used, FPHSA() now also checks all required COMPONENTS,
i.e. all elements from <name>_FIND_COMPONENTS for which <name>_FIND_REQUIRED_<comp>
is true, and sets <name>_FOUND only to true if all have been found.
As discussed on cmake-developers.
Alex
This patch adds documentation for OPTIONAL_COMPONENTS to cmFindPackage.cxx,
and also extends Modules/readme.txt significantly with regard to how
components should be handled.
Alex
8485208 Ninja: shell escape $(CMAKE_SOURCE_DIR) and $(CMAKE_BINARY_DIR)
df84767 Ninja: add support for OBJECT_OUTPUTS, fix PrecompiledHeader test case
48eb7fc Ninja: Avoid using 'this' in member initializers
bba37dd Ninja: Fix for PDB files with spaces in the path.
ac800f4 Ninja: Constify use of cmCustomCommand
9a0d5a8 Ninja: add /DEF: flag to linker call
d40eebd Ninja: Add a cache option CMAKE_ENABLE_NINJA to enable the ninja generator.
8c63433 Ninja: Add friend struct so it can access the private ConvertToNinjaPath.
dbe3dce Ninja: add .def file support
f1bb08f Ninja: ensure the output dir exists at compile time
7a6b5f4 Ninja: Remove an unnecessary variable
80ff210 Ninja: Use cmSystemTools::ExpandListArgument to split compile/link commands
d2731a3 Ninja: Add a missed license header
eabc9b0 Ninja: CMake: Adapt Ninja generator for per-target include dirs
bada88e Merge branch 'target-include-directories' into ninja-generator
54bd175 Ninja: windows msvc: create for each target a .pdb file
...
Xcode 4.3 installs into "/Applications" by default, from the Mac App Store.
Also, the paths to the available SDKs changed: they are now within the
Xcode.app bundle.
PackageMaker is installed as a separate program, and may be installed
anywhere. It is not installed with Xcode 4.3 by default anymore.
Download the "Auxiliary Tools for Xcode" to get PackageMaker.
Put PackageMaker inside the Xcode.app bundle, in its nested Applications
folder, or put it alongside Xcode in "/Applications" and CMake will find
it.
Update references to "find" paths: add new possible locations for finding
Xcode.app and PackageMaker.app. Prefer the most recent version's locations
first, but keep the old locations as fallback search paths, too.
Thanks to all the contributors who provided and tested out various patches
for fixing this issue. Especially, but by no means limited to:
Francisco Requena Espí, Jamie Kirkpatrick and drfrogsplat.
The function configure_package_config_file() may be used instead of
configure_file() for generating the Config.cmake files for installation,
they help to make those files relocatable.
Alex
678c24d FindQt3: fix detection of Qt3 include directory
91a1670 FindQt3: let FPHSA handle the version selection
9dae4d6 FindQt3: fix version extraction for versions with letters
2cd898d FindQt3: fix warning when Qt3 is not found
4689eed reflect that the QtAutomoc depends on QtGui
ab9661c Remove QtGui dependency in Qt4Deploy test and verify QtSql existance.
52e8279 Fix for Qt4Deploy on some test machines.
672e3bb Add test for DeployQt4.cmake
4853e1e Fix plugin installation issues.
35cbf23 Ensure libs are passed to BundleUtilities.
0ac1535 Fix bad plugin paths.
a2123e8 Fix mismatched arguments.
fc6f340 Don't use QT_LIBRARIES_PLUGINS by default.
53d02ea FindPythonLibs: stop scanning when libraries are found
91d5a2a FindPythonLibs: put debug libraries into PYTHON_LIBRARIES
c9c1a17 FindPythonLibs: get the exact version of the found library (#3080)
f772378 FindPythonLibs: make the version selection work as for PythonInterp
bbddaee FindPython{Interp,Libs}: document Python_ADDITIONAL_VERSIONS as input
There are versions out there that neither understand --version nor -V. Try a
completely different approach: execute a small python script that prints the
version number (and only that) in an easily reusable way using
sys.version_info. This is documented to work since Python 2.0. Use sys.version
for older versions, which is documented to exist since 1.5. If even that
doesn't work then simply assume we are on 1.4.0.
This concerns all variables common to all CPack generators.
Variables mainly used and/or set in CPack.cmake are documented
therein. C++ built-in variables are documented in
cmCPackDocumentVariables.cxx.
Use CMAKE_<LANG>_COMPILER_VERSION instead of calling the compiler. This macro
predates those useful variables. This also fixes the issue that g++ version
detection was not working if C language was not enabled.
35c48e1 Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIES
61cb4ea bootstrap: move while() and endwhile() into the bootstrap build
c9f2886 -don't pull in CheckTypeSize.cmake from the cmake which is being built
628f365 -remove trailing whitespace
Add the function cmake_expand_imported_targets() to expand imported
targets in a list of libraries into their on-disk file names for a
particular configuration. Adapt the implementation from KDE's
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES which has been in
use for over 2 years. Call the function from all the Check*.cmake
macros to handle imported targets named in CMAKE_REQUIRED_LIBRARIES.
Alex
A lot of the libraries won't be found by default so will spit out
all sorts of errors. Don't kill QT_LIBRARIES_PLUGINS altogether as
it is sometimes useful.
The Borland compiler was re-branded as CodeGear during 2007-2009 and
since 2009 is the Embarcadero compiler. They offer predefined macros:
http://docwiki.embarcadero.com/RADStudio/en/Predefined_Macros
and distinguish themselves by __CODEGEARC__ and __CODEGEARC_VERSION__.
Version 6.30 (C++Builder XE) changed the meaning of some flags:
http://docwiki.embarcadero.com/RADStudio/en/C%2B%2B_Compiler_Option_Changes_for_XE
Teach Embarcadero compiler information files to generate build rules
with flags matching the compiler version. Leave the flags unchanged
for old Borland versions. Always set the BORLAND toolchain indicator
for compatibility with existing projects that test it. Also set the
EMBARCADERO indicator for newer toolchains.
The GenerateExportHeaders test was failing on one machine, the version
could not be determined there, so the _gcc_version was empty,
so the first argument to if() was empty, so it complained:
http://open.cdash.org/testDetails.php?test=135623436&build=2016288
Use double quotes to turn the non-existant first argument into an empty
string.
Alex
Since we know which compiler we have we can test those OpenMP flags first that
are likely to be correct. This doesn't make any difference for GNU compilers,
but it should avoid useless try_compiles and output cluttering for all others.
The Borland compiler is now the Embarcadero compiler. Rename the shared
platform information file to reflect this. This does not change the
interface, as old versions are still "Borland", but will allow new
versions released by Embarcadero to be supported cleanly.
Newer Ruby versions (from 1.9 onward) seem to warn if you query Config::CONFIG
and print a warning to use RbConfig instead. RbConfig seems to also work in
older versions, at least in 1.8. Use a macro to query RbConfig first and only
if that doesn't give anything fall back to Config.
This contains a change, which changes the behaviour a bit:
now X11_xf86vmode_FOUND is only set to TRUE and the include directory
is added to X11_INCLUDE_DIR, if additionally to X11_xf86vmode_INCLUDE_PATH
also X11_Xxf86vm_LIB has been found.
I hope this doesn't cause regressions somewhere.
Alex
Configure the build_mingw.cmake.in config_mingw.cmake.in files
into the binary directory of the directory being built, not the
top level binary directory for the project.
This also cleans up a bunch of things on the way:
-when perl was queried for paths they were not converted to CMake style on
Windows.
-the result when perl was queried for the perl library name was ignored since
it was expanded with the possible paths, which is not a valid input for
find_library(). If perl returns a library name we now will look only for this
name and not for the default names and use the default names only when the
executable does not give us a hint.
-get rid of 2 variables that were only used at one place and directly put the
values in the call to find_library() and find_path().
Inspired by Jeff Trull
1e16406 CMakeAddFortranSubdirectory: Add NO_EXTERNAL_INSTALL option
6f6891b CMakeAddFortranSubdirectory: Always parse arguments
48a09f8 CMakeAddFortranSubdirectory: Make IMPORTED targets GLOBAL
067c1f4 VSGNUFortran: Disable test in special cases
bd69e1c VSGNUFortran: Add special case for SunPro Fortran runtime library
414a780 CMakeAddFortranSubdirectory: Validate gfortran architecture
7e0d9f1 CMakeAddFortranSubdirectory: Find gfortran in PATH
d6b0312 CMakeAddFortranSubdirectory: Fix documentation format and typos
e4ae038 CMakeAddFortranSubdirectory: Allow full paths to directories
538c345 Add CMakeAddFortranSubdirectory to use MinGW gfortran in VS
3c6af5f Merge branch 'add-CheckLanguage-module' into CMakeAddFortranSubdirectory
d4b77eb Avoid discovering system infos for documentation. Adding some path is enough.
9002f73 Fix non existent std::string::clear on VS6
02ccb32 Create getDocumentedModulesListInDir which may be used in other context.
24fbc28 Add missing section markup for CPackComponent
bafd8a9 Example of builtin variable documentation (i.e. only used in C++ source code).
543f1ad Make the load of script documentation more efficient and dynamic.
cdbd1a9 Fix another compiler warning due to a typo
52c53de Really avoid compiler warning about unused vars
37f90ed Calm down compiler warning about unused var
7c82b7f Fix potential bad memory access, thanks to Eike
62b589b Suppress unused var, beautify code, avoid 1 extra newline.
751713f Update bash completion file in order to handle new CPack doc options.
1629615 CPack Documentation extraction from CMake script begins to work
83e34dd Implement simple CMake script comment markup language.
c6a0169 CPack begin the implementation of --help-command* and --help-variables*
CPack help will be searched in any CPack*.cmake file located
near to CPack.cmake file. The script files is parsed iff
the first line begin with ##section. Moreover the documentation
section name is specified on the remaining part of the line
minus the space immediately following ##section.
The functions in FindGettext create a custom target. If the functions
are called multiple times, multiple times the same target is created.
This works only if CMP0002 is set to OLD.
With this patch there is only one central target created, and each
invocation of the function creates a target with a unique name and
make the central target depend on this one.
Alex
Also, removed detection of header file from <PREFIX>/include.
Can't find any example in alsa source code where the library headers
were installed outside of <PREFIX>/include/alsa.
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.
Verify that MINGW_GFORTRAN not only points to a MinGW gfortran but also
one that compiles for the target architecture. This prevents using a
32-bit gfortran in a 64-bit MSVC build.
In the find_program(MINGW_GFORTRAN) call use the PATHS option for
hard-coded guesses instead of HINTS. This allows the user environment
to override the guesses and corrects usage of the command options.
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.
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.
Causes compiler modules (currently only GNU) to set a
CMAKE_DEPFILE_FLAGS_${lang} variable, which communicates to
the generator the flags required to cause the compiler to create
dependency files.
CHECK_INCLUDE_FILES("foo.h" HAVE_FOO_H) gave an output like:
Looking for include files HAVE_FOO_H
After this change it does now what CHECK_INCLUDE_FILE() also does:
Looking for include files foo.h
When using the NSIS generator from CPack the file NSIS.template.in is
used to generate a project.nsi file for NSIS to process. The file
consists code in the NSIS scripting language. Among other functions
there is an onInit function the initializes the installer. The function
(tries to) recognise admin and power users but fails since NSIS
scripting language relative includes the jump from the current command
so +3 means "run the third command after this one", so a failed check
for admin completely skips the check for a power user and goes directly
to "done:".
User permission lookup was added in initial NSIS support by commit
a11b9a4c (Merge from CPack branch, 2006-01-01). Later commit b1b052fd
(Several changes to for NSIS, 2006-03-01) added a line inside a block
that should be skipped by a jump without updating the jump length.
Update the jump length to correct the behavior.
If the debug and release libraries are the same (which usually means only one
of them was found) do not output the library as "optimized" and "debug", but
just as one plain library. At the end this means that the Find* output of the
avarage (Un*x) user will be much less cluttered.
RUBY_VERSION was always set, even if no RUBY_EXECUTABLE was found. While it
may make sense to assume a default version if we can't execute the binary, it
certainly doesn't make sense to report a version if there is no executable at
all.
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.
bb2b264 FindOpenSSL: also parse version number define with uppercase letters
7053a00 FindOpenSSL: only try to parse opensslv.h if it exists
44ba7a3 Merge branch 'master' of git://cmake.org/cmake into openssl-version
8e8672c FindOpenSSL: improve version number handling
- Enhance extract doc parser. Seems robust now. The legacy
module documentation parser works as before ignoring
the new markup.
- Proof of concept for CPack (generic), CPack RPM and CPack Deb
generator for macro and variables.
Try cpack --help-command and cpack --help-variables
The language is very simple. It use ##<keyword> special comment
which opens a structured documentation block and ##end closes it.
This may be used to extract documentation for macro as 'command'
and 'variables' such that cpack --help-command and --help-variable
does parse builtin modules files (CPack.cmake, CPackComponent.cmake,
...) in order to extract the corresponding doc.
QNX has the phtread stuff in the standard library. The best way would
IMHO be to check if a program that uses pthread_* can be successfully
linked without specifying any linker option before trying out the
different flags.
Change to consider a library embedded if it is found in a subdirectory relative to the
using executable/library. Previous commit considered them local.
This case is encountered when @rpath is used with framework libraries, which are inside a directory tree.
On dashmacmini2 the test showed output like this:
-- Found PythonInterp: /usr/bin/python (found version "Unknown option: --
usage: /usr/bin/python [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.")
On my machine where python outputs "Python 2.7" this worked, but
PYTHON_VERSION_MAJOR, PYTHON_VERSION_MINOR, and PYTHON_VERSION_PATCH were all
set to "2.7".
Add some checks that the version output has the expected form before using it.
This allows the developer to tell FindPythonInterp which Python version should
be searched for. This allows the right version to be chosen for a project
without user assistance if there are specific requirements. This is especially
useful as it is common to have major versions 2 and 3 installed in parallel,
which are partly incompatible.
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)
Otherwise the compiler may optimize out the reference to the symbol as the
previous version was not really using this. This leads to symbols that are
only in a header but not in the given libraries to be reported as present.
This came up on the first try to fix bug 11333 as "gcc -O3" would optimize
out the reference to pthread_create() so the correct library the symbol is in
was not detected.
The new test code was suggested by Brad King.
When we have no MPI compiler wrapper and search explicitly for the MPI
C++ library append it correctly to the list of libraries instead of
using a space.
Suggested-by: Mourad Boufarguine <bouffa@gmail.com>
This fix bug #12863 whose symptom was a lot of "warning: File listed twice"
printed out by rpmbuild when processing the spec file.
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
First this fixes the bug that e.g. version "1.0.0" was shown as "1..". When
pkg-config was used to find OpenSSL the header file was parsed for the version
number even if pkg-config returned it already. Finally we also include the
patch level (i.e. the letter after the version number) in OPENSSL_VERSION.
When GIT_EXECUTABLE points at ".../Git/cmd/git.cmd" in an msysGit
installation we previously failed to detect the version number in a
subtle case. The "git.cmd" assumes 'chcp' is in PATH. It is typically
available at "C:\Windows\System32\chcp.com". On 64-bit Windows the File
System Redirector maps this location to "C:\Windows\SysWOW64\chcp.com"
for 32-bit processes. However, some Windows installations fail to
provide chcp.com at this path. Whenever git.cmd runs in a 32-bit
command shell, as it does under a 32-bit CMake binary, it reports
'chcp' is not recognized as an internal or external command,
operable program or batch file.
on stderr. Capture stderr separately so it does not affect parsing
of the version number.
See also msysGit issue 358:
http://code.google.com/p/msysgit/issues/detail?id=358
Note that FindGit prefers "git.cmd" over "git.exe" because it sets up
the proper HOME environment variable necessary for Git ssh connections
to work the same as they do from the Git bash prompt.
Decode decimal digits from _SGI_COMPILER_VERSION or _COMPILER_VERSION to
compute version number components. See documentation at:
http://predef.sourceforge.net/precomp.html
The MSVC, HP, XL, SunPro, Watcom, Borland, and Intel compilers specify
their version number in components encoded in a single integer value.
Document the components that we use to compute version numbers.
Decode hex digits from __SUNPRO_C and __SUNPRO_CC to compute the version
number components. Note that the constant encodes decimal digits as hex
digits (never larger than 9). We represent them as decimal after
extraction. See documentation at
http://predef.sourceforge.net/precomp.html
Although the documented version number format is
0xVRP where V = Version, R = Revision, P = Patch
it holds only though SunPro C/C++ version 5.9. Later versions have
a two-digit revision (minor) number so their format is 0xVRRP.
When cmake searches for Python libs in Windows it searches in:
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
However, the information might not always reside there. The information
could also reside in:
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
when one installs Python for a single user and not for all users.
Fix typo introduced in commit 66a08c10 (more uniform approach to enable
language, 2004-08-26). The optimization option should be /O2 for
Release configurations and /O1 for MinSizeRel.
Suggested-by: He Yuqi <yuqi.he@gmail.com>
This addresses Bug 11882 which provided a sample implementation for adding
support for cusparse. I went ahead and added all the libraries I thought
appropriate.
Added support for additional import paths during protoc invocation
time to the PROTOBUF_GENERATE_CPP public macro via a new
PROTOBUF_IMPORT_DIRS optional variable.
Patch courtesy of Miroslav Kes <mkes@ra.rockwell.com>
The default OS X 10.4 linker incorrectly searches for dependencies of
linked shared libraries only under the -isysroot location. It fails to
find dependencies of linked shared libraries in cases such as the
ExportImport test. It produces errors like:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
libtestLib3Imp.dylib
referenced from: /.../ExportImport/Root/lib/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _testLib3Imp
referenced from libtestLib3lib expected to be defined in
libtestLib3Imp.dylib
or with CMAKE_SKIP_RPATH off to enable install_name in the Export side:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.4u.sdk/.../ExportImport/Export/impl/libtestLib3Imp.dylib
referenced from: /.../ExportImport/Export/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:_testLib3Imp
referenced from libtestLib3lib expected to be defined in
/.../ExportImport/Export/impl/libtestLib3Imp.dylib
Note how "/Developer/SDKs/MacOSX10.4u.sdk" is prepended to the dependent
library path.
Commit 2cff26fa (Support linking to shared libs with dependent libs,
2008-01-31) and commit 82fcaebe (Pass dependent library search path to
linker on some platforms, 2008-02-01) worked around the problem by
defining platform variable CMAKE_LINK_DEPENDENT_LIBRARY_FILES. It tells
CMake to link to dependent libraries explicitly by their path thus
telling the linker where to find them.
Unfortunately the workaround had the side effect of linking dependent
libraries and defeats most benefits of LINK_INTERFACE_LIBRARIES.
Fortunately OS X 10.5 and above do not need to find transitive
dependencies at all so we can avoid the workaround on Modern OS X.
Previously we linked C, Fortran, and ASM shared libraries compiled with
the HP compiler using a direct invocation of the linker (ld). This
behavior was left historically from support for an ancient HP C compiler
that did not know how to create shared libraries. Fortran shared
libraries need to be linked with the compiler to get the language
runtime library dependencies as is already done for C++.
Update the HP-UX-HP* platform information to use the compiler front end
when linking shared libraries. This works on modern HP tools and
produces correct behavior. If there is a need to support older tools
again we can add a special case for them.
...if it matches "windres", as opposed to being exactly equal to "windres"
Cross-compiling windres compilers are named something like
"i686-w64-mingw32-windres" (for example)
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
The User may now specific a list of file that shouldn't be
automatically handled by CPack but specified by the user.
Like %config(noreplace) or specific %attr.
The concerned files/dir lines will be removed from the set
automatically handled by CPack.
The mingw32-make tool does not handle parenthesis in the path to a
source file consistently. When CMake is installed in a typical location
like "c:\Program Files (x86)\CMake 2.8\" the mingw32-make tool fails on
the FortranCInterface detection project sometimes with errors like
>mingw32-make -f CMakeFiles\myfort.dir\build.make CMakeFiles/myfort.dir/my_module.f90.obj
mingw32-make: *** No rule to make target `x86)/CMake 2.8/share/cmake-2.8/Modules/FortranCInterface/my_module.f90)',
needed by `CMakeFiles/myfort.dir/my_module.f90.obj'. Stop.
due to parens in the path to the FortranCInterface source directory.
However, the behavior varies with the file name of build.make:
>copy CMakeFiles\myfort.dir\build.make CMakeFiles\myfort.dir\build2.make
>mingw32-make -f CMakeFiles\myfort.dir\build2.make CMakeFiles/myfort.dir/my_module.f90.obj
[ 3%] Building Fortran object CMakeFiles/myfort.dir/my_module.f90.obj
Tested with
>mingw32-make -v
GNU Make 3.82
Built for i386-pc-mingw32
Work around the problem by copying the whole FortranCInterface source
directory in to the project build tree.
2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling
1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE
bc278ce automoc: fix line length
62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing
40c5167 automoc: accept even more .moc files in non-strict mode
c207f5d automoc: also accept other files when .moc is included in non-strict mode
9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible
174bf35 automoc: move the code for finding headers into separate function
8507eae automoc: fix handling of included _p.moc files
7ada172 automoc: some more linebreaks for the warnings for better readability
3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT
4745715 Add a test case for the use of Q_PRIVATE_SLOT.
bde4edb automoc: add special handling for including basename_p.moc, with test
74ab0f6 automoc: move some code from the big parsing loop into separate functions
bc7560e automoc: add test for including a moc_abc_p.cpp file
30fd8e6 automoc: add test for including the moc file from another header
...
David Cole
Rolf Eike Beer
Brad King
Patrick Gansterer
Modestas Vainius
Ben Boeckel
Tom Hughes
Eric NOULARD
Alex Neundorf
Kashif Rasul
Peter Collingbourne
Bill Hoffman
Clinton Stimpson
Droscy
Stephen Kelly
Yury G. Kudryashov
Mike McQuaid
Peter Kuemmel
Alexey Ozeritsky
Nicolas Despres
Matthias Kretz
Philip Lowman
Mattias Helsing
Deborah Pickett
Christian Andersson
Michael Wild
Jason Erb
James Bigler
Tim Gallagher