[cmake-developers] [CMake 0012869]: FindPythonLibs.cmake fails as it searches in the wrong place
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12869
==
Reported By:Christian Andersson
Assigned To:
==
Project:CMake
Issue ID: 12869
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-01-10 05:20 EST
Last Modified: 2012-01-10 05:20 EST
==
Summary:FindPythonLibs.cmake fails as it searches in the
wrong place
Description:
When cmake searches for Python libs in Windows it searches in (from
FindPythonLibs.cmake):
[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
As it is on my machine. The difference is I suspect is that it is dependent on
if a user installs Python for just himself or if Python is installed for all
users on the current machine.
Steps to Reproduce:
Install Python for a single user, not for all users.
Additional Information:
I uploaded a patch where one can see what is needed to be added in
FindPythonLibs.cmake.
Best Regards
/Christian
==
Issue History
Date ModifiedUsername FieldChange
==
2012-01-10 05:20 Christian AnderssonNew Issue
2012-01-10 05:20 Christian AnderssonFile Added: FindPythonLibs2.patch
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012870]: CMakeDetermineRCCompiler does not correctly identify GNU windres when cross-compiling
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12870
==
Reported By:Sam Morris
Assigned To:
==
Project:CMake
Issue ID: 12870
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-01-10 07:29 EST
Last Modified: 2012-01-10 07:29 EST
==
Summary:CMakeDetermineRCCompiler does not correctly identify
GNU windres when cross-compiling
Description:
I'm cross compiling on Linux with CMAKE_SYSTEM_NAME set to Windows.
CmakeDetermineRCCompiler contains the following code:
GET_FILENAME_COMPONENT(_CMAKE_RC_COMPILER_NAME_WE ${CMAKE_RC_COMPILER} NAME_WE)
IF(_CMAKE_RC_COMPILER_NAME_WE STREQUAL windres)
SET(CMAKE_RC_OUTPUT_EXTENSION .obj)
ELSE()
SET(CMAKE_RC_OUTPUT_EXTENSION .res)
ENDIF()
CMAKE_C_COMPILER is set to 'i686-w64-mingw32-windres', therefore the above code
goes down the wrong branch, and ends up setting CMAKE_RC_OUTPUT_EXTENSION to
'.res'.
Additional Information:
I'm actually trying to debug a separate problem: nothing is processing
Modules/Platform/Windows-windres.cmake and I don't know why. I mention this here
because I see the above code was added in the same commit that
Windows-windres.cmake was added:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2f308c8
==
Issue History
Date ModifiedUsername FieldChange
==
2012-01-10 07:29 Sam Morris New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012871]: add_definitions adds flags to RC_DEFINES
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12871 == Reported By:Sam Morris Assigned To: == Project:CMake Issue ID: 12871 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-01-10 09:53 EST Last Modified: 2012-01-10 09:53 EST == Summary:add_definitions adds flags to RC_DEFINES Description: The attached project tries to create an executable from a C++ file and a Windows resource script: CMakeLists.txt contains: project(restest) add_definitions(-msse) add_executable(a a.cpp a_res.rc) The build fails because -msse ends up in RC_DEFINES, which is passed to windres to compile the resource script. Steps to Reproduce: $ make VERBOSE=1 /usr/bin/cmake -H/home/sam/src/cmake/rc -B/home/sam/src/cmake/rc/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/sam/src/cmake/rc/build/CMakeFiles /home/sam/src/cmake/rc/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/home/sam/src/cmake/rc/build' make -f CMakeFiles/a.dir/build.make CMakeFiles/a.dir/depend make[2]: Entering directory `/home/sam/src/cmake/rc/build' cd /home/sam/src/cmake/rc/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/sam/src/cmake/rc /home/sam/src/cmake/rc /home/sam/src/cmake/rc/build /home/sam/src/cmake/rc/build /home/sam/src/cmake/rc/build/CMakeFiles/a.dir/DependInfo.cmake --color= make[2]: Leaving directory `/home/sam/src/cmake/rc/build' make -f CMakeFiles/a.dir/build.make CMakeFiles/a.dir/build make[2]: Entering directory `/home/sam/src/cmake/rc/build' /usr/bin/cmake -E cmake_progress_report /home/sam/src/cmake/rc/build/CMakeFiles 2 [ 50%] Building RC object CMakeFiles/a.dir/a_res.res /usr/bin/i686-w64-mingw32-windres -O coff -msse /home/sam/src/cmake/rc/a_res.rc CMakeFiles/a.dir/a_res.res /usr/bin/i686-w64-mingw32-windres: invalid option -- 'm' Usage: /usr/bin/i686-w64-mingw32-windres [option(s)] [input-file] [output-file] The options are: -i --input=fileName input file -o --output=file Name output file -J --input-format=format Specify input format -O --output-format=format Specify output format -F --target=target Specify COFF target --preprocessor=program Program to use to preprocess rc file --preprocessor-arg=arg Additional preprocessor argument -I --include-dir=dir Include directory when preprocessing rc file -D --define sym[=val]Define SYM when preprocessing rc file -U --undefine sym Undefine SYM when preprocessing rc file -v --verbose Verbose - tells you what it's doing -c --codepage=codepage Specify default codepage -l --language=val Set language when reading rc file --use-temp-file Use a temporary file instead of popen to read the preprocessor output --no-use-temp-fileUse popen (default) -r Ignored for compatibility with rc @file Read options from file -h --helpPrint this help message -V --version Print version information FORMAT is one of rc, res, or coff, and is deduced from the file name extension if not specified. A single file name is an input file. No input-file is stdin, default rc. No output-file is stdout, default rc. /usr/bin/i686-w64-mingw32-windres: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex make[2]: *** [CMakeFiles/a.dir/a_res.res] Error 1 make[2]: Leaving directory `/home/sam/src/cmake/rc/build' make[1]: *** [CMakeFiles/a.dir/all] Error 2 make[1]: Leaving directory `/home/sam/src/cmake/rc/build' make: *** [all] Error 2 == Issue History Date ModifiedUsername FieldChange == 2012-01-10 09:53 Sam Morris New Issue 2012-01-10 09:53 Sam Morris File Added: rc.tar.gz == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check
[cmake-developers] RFC: standard (and not so standard) install dirs
Hi,
here comes a quite lengthy mail on issues I see in KDE but also in general
with install dirs and CMake.
in KDE we define a set of variables which hold the install destinations for
several different file types:
EXEC_INSTALL_PREFIX(${CMAKE_INSTALL_PREFIX})
SHARE_INSTALL_PREFIX (share)
BIN_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/bin)
SBIN_INSTALL_DIR (${EXEC_INSTALL_PREFIX}/sbin)
LIB_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX})
LIBEXEC_INSTALL_DIR(${LIB_INSTALL_DIR}/kde4/libexec)
INCLUDE_INSTALL_DIR(include)
PLUGIN_INSTALL_DIR (${LIB_INSTALL_DIR}/kde4)
IMPORTS_INSTALL_DIR(${PLUGIN_INSTALL_DIR}/imports)
CONFIG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config)
DATA_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/apps)
HTML_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/doc/HTML)
ICON_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/icons)
KCFG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config.kcfg)
LOCALE_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/locale)
MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mimelnk)
SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/services)
SERVICETYPES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/servicetypes)
SOUND_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/sounds)
TEMPLATES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/templates)
WALLPAPER_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/wallpapers)
DEMO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/demos)
KCONF_UPDATE_INSTALL_DIR (${DATA_INSTALL_DIR}/kconf_update)
AUTOSTART_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/autostart)
XDG_APPS_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/applications/kde4)
XDG_DIRECTORY_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/desktop-directories)
XDG_MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mime/packages)
SYSCONF_INSTALL_DIR(${CMAKE_INSTALL_PREFIX}/etc)
MAN_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/man)
INFO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/info)
DBUS_INTERFACES_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/dbus-1/interfaces)
DBUS_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/services)
DBUS_SYSTEM_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/system-
services)
As you can see, some of them are very generic, and make sense for about any
package, like LIB_INSTALL_DIR and BIN_INSTALL_DIR, some are quite KDE-
specific, like SERVICETYPES_INSTALL_DIR and KCONF_UPDATE_INSTALL_DIR, some are
related to other packages, like e.g. XDG_DIRECTORY_INSTALL_DIR and
DBUS_SERVICES_INSTALL_DIR.
These variables are defined in FindKDE4Internal.cmake, so any package doing
find_package(KDE4)
can make use of these variables for installing its stuff.
Which features/advantages does this bring:
1) all these variables can be adjusted via the cache, so users/packagers can
tweak where stuff is installed to
2) the variables which can be tweaked have standard names, so it's the same
for all KDE4-packages
3) and a special extra feature: if a project which uses kdelibs is installed
to the same CMAKE_INSTALL_PREFIX as kdelibs, all these variables are
initialized to the values from kdelibs.
E.g. if kdelibs is installed in /opt/kde, and SYSCONF_INSTALL_DIR was set to
/etc for kdelibs, for any application which does find_package(KDE4) and
where CMAKE_INSTALL_PREFIX is also set to /opt/kde, SYSCONF_INSTALL_DIR will
be set to the value from kdelibs, i.e. /etc.
So far, so good.
With the ongoing modularization of kdelibs we'd like to standardize this a bit
more and using a more generic, non KDE-specific solution.
Now since a few releases CMake has GNUInstallDirs.cmake.
This module serves a similar purpose. Unfortunately it introduced different
names for these variables, but ok.
It provides the following install destinations:
CMAKE_INSTALL_BINDIR (bin)
CMAKE_INSTALL_SBINDIR (sbin)
CMAKE_INSTALL_LIBEXECDIR (libexec)
CMAKE_INSTALL_SYSCONFDIR (etc)
CMAKE_INSTALL_SHAREDSTATEDIR (com)
CMAKE_INSTALL_LOCALSTATEDIR(var)
CMAKE_INSTALL_LIBDIR (lib or lib64)
CMAKE_INSTALL_INCLUDEDIR (include)
CMAKE_INSTALL_OLDINCLUDEDIR(/usr/include)
CMAKE_INSTALL_DATAROOTDIR (share)
CMAKE_INSTALL_DATADIR (DATAROOTDIR)
CMAKE_INSTALL_INFODIR (DATAROOTDIR/info)
CMAKE_INSTALL_LOCALEDIR(DATAROOTDIR/locale)
CMAKE_INSTALL_MANDIR (DATAROOTDIR/man)
CMAKE_INSTALL_DOCDIR (DATAROOTDIR/doc/PROJECT_NAME)
This is mostly a subset of the variables defined by KDE.
There are some additional variables (CMAKE_INSTALL_OLDINCLUDEDIR,
CMAKE_INSTALL_SHAREDSTATEDIR, CMAKE_INSTALL_LOCALSTATEDIR) which do not
[CMake] CPack output name using VS IDE
Hi,
I want my Install package from CPack to have Debug or Release in its name.
In my CMake file I have
set(CPACK_PACKAGE_NAME
MyPackage-${CMAKE_BUILD_TYPE})
But when executing the PACKAGE target, from within VS IDE, the
${CMAKE_BUILD_TYPE} does not seem to be set.
Any tips?
totte
--
.
Totte Karlsson, Ph.D.
Dune Scientific, LLC
425-296 1980 (office)
425-780 9648 (cell)
www.dunescientific.com
.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack output name using VS IDE
2012/1/10 Totte Karlsson to...@dunescientific.com:
Hi,
I want my Install package from CPack to have Debug or Release in its name.
In my CMake file I have
set(CPACK_PACKAGE_NAME
MyPackage-${CMAKE_BUILD_TYPE})
But when executing the PACKAGE target, from within VS IDE, the
${CMAKE_BUILD_TYPE} does not seem to be set.
VS IDE or XCode do not set this because they are able to handle
several config at once.
You may try to use CMAKE_CFG_INTDIR instead.
See:
cmake --help-variable CMAKE_CFG_INTDIR
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Actual effect of set_source_files_properties with COMPILE_FLAGS
Hello everybody,
I work on a Fortran library that for historical reasons should be
maintained with intel fortran compiler, g95 and gfortran
on Linux, Windows and MacOS platoform. Everything everywhere :o !
My library is made of 50 files. Among those files, most of them will
have to be compiled with a set of flags that
does not match the CMake default ones. But, for a few of them (4
actually) there are some slight variations. For instance,
with g95, 46 files has to compiled with -std=f2003 while the 4 others
ones should have this flag unset.
The strategy I decided to adopt is the following:
- use of a macro to set the standard flags (see attached file
set_compiler_flags.cmake)
- use of set_source_files_properties(${SOURCES} PROPERTIES
COMPILE_FLAGS -std=f2003)
to set the -std=f2003 flag for all the files.
- use of set_source_files_properties(file1.f90 PROPERTIES
COMPILE_FLAGS ) to switch off the -std=f2003
flag for the files for which that flag should not be set.
does it look reasonable to you ?
Now my problem. When cmaking my project, I get in one subdirectories of
CMakeFiles a file flags.make that contains the compiler flags. From that
file, it seems that the set_source_files_properties commands were
correctly executed (guessing that the comment for Custom flags is not an
actual comment). But when using nmake in verbose mode, the custom flags
do not appear in the g95 command line. The only ones displayed are the
one set in my set_compiler_flags macro. Is that just a bug on the
display or is there something wrong with my settings ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
macro(set_compiler_flags)
get_filename_component(COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME_WE)
if(COMPILER_NAME STREQUAL ifort)
if(WIN32)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -debug:full /check /traceback
/nologo)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE /O2 /nologo /Qvec-report0)
endif()
elseif(APPLE)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -warn)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O -warn -vec-report0)
endif()
else()
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -warn)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O -warn -vec-report0)
endif()
endif()
elseif(COMPILER_NAME STREQUAL g95)
if(WIN32)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -O0 -ftrace=full)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O3 -funroll-loops -msse2)
endif()
elseif(APPLE)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -Wall)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O)
endif()
else()
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -Wall)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O)
endif()
endif()
elseif(COMPILER_NAME STREQUAL gfortran)
if(WIN32)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -O0 -ftrace=full)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O3 -funroll-loops -msse2)
endif()
elseif(APPLE)
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -Wall -m32)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O -m32)
endif()
else()
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(CMAKE_Fortran_FLAGS_DEBUG -g -Wall)
elseif(CMAKE_BUILD_TYPE STREQUAL Release)
set(CMAKE_Fortran_FLAGS_RELEASE -O)
endif()
endif()
endif()
endmacro()# CMAKE generated file: DO NOT EDIT!
# Generated by NMake Makefiles Generator, CMake Version 2.8
# Custom flags:
CMakeFiles/crysfml_common.dir/CFML_GlobalDeps_Windows.f90.obj_FLAGS = -std=f2003
# Custom flags: CMakeFiles/crysfml_common.dir/CFML_Atom_Mod.f90.obj_FLAGS =
-std=f2003
# Custom flags: CMakeFiles/crysfml_common.dir/CFML_Bonds_Table.f90.obj_FLAGS =
-O0
# Custom flags: CMakeFiles/crysfml_common.dir/CFML_Chem_Scatt.f90.obj_FLAGS =
-O0
# Custom flags: CMakeFiles/crysfml_common.dir/CFML_Conf_Calc.f90.obj_FLAGS =
-std=f2003
# Custom
Re: [CMake] CPack output name using VS IDE
But when executing the PACKAGE target, from within VS IDE, the
${CMAKE_BUILD_TYPE} does not seem to be set.
VS IDE or XCode do not set this because they are able to handle
several config at once.
yes.
You may try to use CMAKE_CFG_INTDIR instead.
See:
cmake --help-variable CMAKE_CFG_INTDIR
When executing the PACKAGE target from the IDE, that variable is evaluated to
$(Configuration)
Still don't get how to get the actual 'configuration' string, i.e. Debug/Release
etc, when executing the PACKAGE target in visual studio.
totte
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack output name using VS IDE
2012/1/10 Totte Karlsson to...@dunescientific.com:
But when executing the PACKAGE target, from within VS IDE, the
${CMAKE_BUILD_TYPE} does not seem to be set.
VS IDE or XCode do not set this because they are able to handle
several config at once.
yes.
You may try to use CMAKE_CFG_INTDIR instead.
See:
cmake --help-variable CMAKE_CFG_INTDIR
When executing the PACKAGE target from the IDE, that variable is evaluated
to
$(Configuration)
Still don't get how to get the actual 'configuration' string, i.e.
Debug/Release etc, when executing the PACKAGE target in visual studio.
Ah...yes that's true.
The problem is that this variable [$(Configuration)] is evaluated
at build time
so that you cannot get a value at CMake-time (when CMake is running).
see:
Since these values are evaluated by the native build system, this
variable is suitable only for use in command lines that will be
evaluated at build time.
Moreover I don't really know how to get that value when CPack is running
(be it from PACKAGE or from command line). I guess one have to
pass the value from the command line (or internal tool call)
generated for the PACKAGE target.
You may probably hand-craft you own custom_command/target for that
but don't know how to add this to the built-in PACKAGE target.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack output name using VS IDE
On 01/10/2012 10:50 AM, Totte Karlsson wrote:
But when executing the PACKAGE target, from within VS IDE, the
${CMAKE_BUILD_TYPE} does not seem to be set.
VS IDE or XCode do not set this because they are able to handle
several config at once.
yes.
You may try to use CMAKE_CFG_INTDIR instead.
See:
cmake --help-variable CMAKE_CFG_INTDIR
When executing the PACKAGE target from the IDE, that variable is
evaluated to
$(Configuration)
Not quite. CMake evaluates it to $(Configuration) (or what ever the
particular IDE uses), which then gets expanded by the IDE to the current
configuration, i.e. Debug, Release, etc.
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding user defined search path for find_package
Dear CMake community, firstly, thank you for the extremely useful build tool, it's saved me a lot of time and effort! I'm trying to solve the following problem: I'd like the user (i.e. non-developer compiling my code) to have the option to specify a location for an external library and *iff* this option is set it should be used as the 'top-priority' search location for that library, falling back to all the others if it is not found or not set. Ideally this option would be set as a variable so that it is visible in e.g. ccmake. The reason for doing this is that if the user just sets a variable to indicate the library path I would then have to manually check that the library does indeed exist at that path. Is there a way to do this? Many thanks, -Martin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding user defined search path for find_package
On 01/10/2012 11:14 AM, Martin Uhrin wrote: Dear CMake community, firstly, thank you for the extremely useful build tool, it's saved me a lot of time and effort! I'm trying to solve the following problem: I'd like the user (i.e. non-developer compiling my code) to have the option to specify a location for an external library and *iff* this option is set it should be used as the 'top-priority' search location for that library, falling back to all the others if it is not found or not set. Ideally this option would be set as a variable so that it is visible in e.g. ccmake. The reason for doing this is that if the user just sets a variable to indicate the library path I would then have to manually check that the library does indeed exist at that path. Is there a way to do this? Many thanks, -Martin There are quite a few such variables: CMAKE_PREFIX_PATH CMAKE_LIBRARY_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_FRAMEWORK_PATH CMAKE_APPBUNDLE_PATH CMAKE_IGNORE_PATH Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cpack -G NSIS
Trying to run cpack on Linux (archlinux 64 bit) with a working makensis environment, I get the following error (and following stacktrace): [andrea@precision test_cmake]$ gdb cpack GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/cpack...(no debugging symbols found)...done. (gdb) run -G NSIS Starting program: /usr/bin/cpack -G NSIS [Thread debugging using libthread_db enabled] terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct null not valid Program received signal SIGABRT, Aborted. 0x76c90935 in raise () from /lib/libc.so.6 (gdb) bt #0 0x76c90935 in raise () from /lib/libc.so.6 #1 0x76c91dab in abort () from /lib/libc.so.6 #2 0x772d11ed in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6 #3 0x772cf396 in ?? () from /usr/lib/libstdc++.so.6 #4 0x772cf3c3 in std::terminate() () from /usr/lib/libstdc++.so.6 #5 0x772cf4be in __cxa_throw () from /usr/lib/libstdc++.so.6 #6 0x7727c1f7 in std::__throw_logic_error(char const*) () from /usr/lib/libstdc++.so.6 #7 0x772ba039 in char* std::string::_S_constructchar const*(char const*, char const*, std::allocatorchar const, std::forward_iterator_tag) () from /usr/lib/libstdc++.so.6 #8 0x772ba113 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) () from /usr/lib/libstdc++.so.6 #9 0x0048a9f6 in cmCPackNSISGenerator::InitializeInternal() () #10 0x0047b784 in cmCPackGenerator::Initialize(char const*, cmMakefile*) () #11 0x00474562 in main () Any idea about what it could be? Thanks, Andrea -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -G NSIS
2012/1/10 Andrea Crotti andrea.crott...@gmail.com: Trying to run cpack on Linux (archlinux 64 bit) with a working makensis environment, Which version of cmake/cpack are you using? If not 2.8.7 could you try it? or even git master? Did you compile it yourself? Are you cross-compiling? If this is the case may be you hit something similar to: http://www.cmake.org/pipermail/cmake/2011-December/048123.html I get the following error (and following stacktrace): [andrea@precision test_cmake]$ gdb cpack GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/cpack...(no debugging symbols found)...done. (gdb) run -G NSIS Starting program: /usr/bin/cpack -G NSIS [Thread debugging using libthread_db enabled] terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct null not valid This means that we tried to construct an std::string using a NULL pointer. May be you compile a debug version of cpack and go straight to the point where it hurts. having the precise line of this context would help: #9 0x0048a9f6 in cmCPackNSISGenerator::InitializeInternal() () Any idea about what it could be? Nope but if you have a small example which reproduce the issue I may have a look into it. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSBuild and automatic project file regenation
Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cmake coloring gcc output on errror
Is there a way to color warning/error of gcc with cmake ? regards Vivek Goel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -G NSIS
2012/1/10 Andrea Crotti andrea.crott...@gmail.com: On 01/10/2012 05:52 PM, Eric Noulard wrote: 2012/1/10 Andrea Crottiandrea.crott...@gmail.com: Trying to run cpack on Linux (archlinux 64 bit) with a working makensis environment, Which version of cmake/cpack are you using? If not 2.8.7 could you try it? or even git master? Did you compile it yourself? Are you cross-compiling? If this is the case may be you hit something similar to: http://www.cmake.org/pipermail/cmake/2011-December/048123.html It's the 2.8.7, but same problem with the git version: [andrea@precision test_cmake]$ /home/andrea/cmake/bin/cpack -G nsis --debug CPack: /home/andrea/cmake/Source/CPack/cpack.cxx:230 Enable Debug CPack Error: /home/andrea/cmake/Source/CPack/cpack.cxx:397 Cannot initialize CPack generator: nsis This does not seems to fail in the same way? (By the way you lack a .gitignore, which for example might contain Bootstrap.cmk) Why? Usually when you build CMake you do it out-of-source: mkdir bstrap cd btstrap /path/to/CMake/bootstrap if you do build in-source you can clean-up using git clean What do you mean cross-compiling? The compiled (target) executable are not the same type as the one of the machine (host) you are compiling. see: https://en.wikipedia.org/wiki/Cross_compiler and the way to go with cmake; http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm on linux and the *exe are supposed to work only on Windows, so yes in that sense I'm cross-compiling. (look like is the same problem of the other thread anyway) Then may be I'll cc Hendrik because in the end he solves his problem but I don't know how. Is your project public shainll try to compile it myself? I am cross-compiling the CERTI project for Windows https://savannah.nongnu.org/projects/certi/ pretty much in similar config as yours: host = Debian Linux 64bit target = win32 using i686-w64-mingw32-gcc/g++ You can try to checkout the latest source: https://savannah.nongnu.org/cvs/?group=certi then cd certi mkdir buildWin32 cd buildWin32 cmake -DCMAKE_TOOLCHAIN_FILE=../scripts/Toolchain-cross-mingw32-linux.cmake .. make cpack -G NSIS this works for me. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
I'd guess the performance of fixup_bundle will be a big pitfall if you're planning on doing this after every build. An entirely different approach is to configure a Visual Studio .user file to set the PATH environment variable (not setting it globally; just for debugging your app from within VS). You still have to track which directories to add to the PATH, but this approach has worked flawlessly for us (across multiple versions of VS, as well as 32- and 64-bit configs). On Mon, Jan 9, 2012 at 8:41 AM, David Cole david.c...@kitware.com wrote: 2012/1/9 Hauke Heibel hauke.hei...@googlemail.com: 2012/1/9 Michael Stürmer m.stuer...@pmdtec.com: Awesome! Sometimes you just need to know what's already available to solve your problems in a very elegant way. I'll have a look at these bundles and probably switch to them instead of maintaining my own stuff! When looking at the initial problem, I am pretty much convinced that you need a combination of your own script and GetPrerequisites since you want to copy to your run-time output directory - and there to specific sub-directories depending on the build type. It may well be that I have overseen some functionality in those new modules ... - Hauke BundleUtilities, on Windows, should copy dlls to be in the same directory as the executable being analyzed... So, as long as the exe is in the right directory when fixup_bundle is called on it, then the dlls will get copied into that same directory. Cheers, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
I am VERY interested in how you did this. Did you have CMake write a file for you? Do you have some code to share by any chance? Thanks -- Mike Jackson www.bluequartz.net On Jan 10, 2012, at 3:17 PM, Ben Medina wrote: I'd guess the performance of fixup_bundle will be a big pitfall if you're planning on doing this after every build. An entirely different approach is to configure a Visual Studio .user file to set the PATH environment variable (not setting it globally; just for debugging your app from within VS). You still have to track which directories to add to the PATH, but this approach has worked flawlessly for us (across multiple versions of VS, as well as 32- and 64-bit configs). On Mon, Jan 9, 2012 at 8:41 AM, David Cole david.c...@kitware.com wrote: 2012/1/9 Hauke Heibel hauke.hei...@googlemail.com: 2012/1/9 Michael Stürmer m.stuer...@pmdtec.com: Awesome! Sometimes you just need to know what's already available to solve your problems in a very elegant way. I'll have a look at these bundles and probably switch to them instead of maintaining my own stuff! When looking at the initial problem, I am pretty much convinced that you need a combination of your own script and GetPrerequisites since you want to copy to your run-time output directory - and there to specific sub-directories depending on the build type. It may well be that I have overseen some functionality in those new modules ... - Hauke BundleUtilities, on Windows, should copy dlls to be in the same directory as the executable being analyzed... So, as long as the exe is in the right directory when fixup_bundle is called on it, then the dlls will get copied into that same directory. Cheers, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
On Tue, Jan 10, 2012 at 3:17 PM, Ben Medina ben.med...@gmail.com wrote: I'd guess the performance of fixup_bundle will be a big pitfall if you're planning on doing this after every build. One other approach is not making it a post build step but a custom target that the user can build only when needed. This custom build step will copy the dlls like the post build step did. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake + Ninja
On Tue, Jan 10, 2012 at 12:03 AM, Peter Collingbourne pe...@pcc.me.uk wrote: The attached patch should add support for TARGET_INSTALLNAME_DIR. Please let me know if it works -- it's untested, as I don't have easy access to a Mac. Awesome - thank you! It'll be a week or so before I have access to a Mac myself, but I'll give it a go once I do. Cheers, CY -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack output name using VS IDE
cmake --help-variable CMAKE_CFG_INTDIR When executing the PACKAGE target from the IDE, that variable is evaluated to $(Configuration) Not quite. CMake evaluates it to $(Configuration) (or what ever the particular IDE uses), which then gets expanded by the IDE to the current configuration, i.e. Debug, Release, etc. In the PACKAGE target it does not seem to get expanded. Any idea how to 'force' such thing. -tk -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: error of mixed dynamic/static link to Boost in windows VS2008
-- Forwarded message --
From: Forest Yang yzine0...@gmail.com
Date: Tue, Jan 10, 2012 at 10:14 PM
Subject: Re: [CMake] error of mixed dynamic/static link to Boost in
windows VS2008
To: Mateusz Loskot mate...@loskot.net
On Fri, Jan 6, 2012 at 5:30 AM, Mateusz Loskot mate...@loskot.net wrote:
On 6 January 2012 05:30, Forest Yang yzine0...@gmail.com wrote:
I am writing a library using boost_regex. For the unit test part, I
am using boost_unit_test_framework and needs to be dynamical linked.
Everything worked great on Linux but not the Windows VS 2008.
I used the BoostPro binary installer, got boost components like:
boost_regex-vc90-mt-gd-1_47.dll and .lib, also the
libboost_regex-vc90-mt-gd-1_47.lib file. After the FIND_PACKAGE(Boost
Components ...) I got the boost_*-vc90-mt-gd-1_47.lib version, (no
prefix lib), however, when I compile the unit test executable, it has
an error fatal error LNK1104: cannot open file
'libboost_regex-vc90-mt-gd-1_47.lib' If I add its directory C:\Program
Files\boost\boost_1_47\lib to the linker's Additional Library
Directory in VS2008 everything went OK.
My question is
1. Where this libboost* comes from ? all my CMake script are giving
boost_* instead of libboost_* libraries.
2. When to set this linker directory so I do not need to add this
manually in VS2008.
The libboost_* libraries are dragged in by auto-linking on Windows.
Auto-linking is ON by default on Windows.
You have to explicitly disable it.
Go to CMake installation directory, locate FindBoost.cmake file,
open this file and read the comments where you have it explained very well.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Thanks for telling me the auto-link part. It works now.
Actually I did look at the FindBoost.cmake, but did not get a direct
answer for my case:
Here is my working case:
ADD_SUBDIRECTORY(src)
ADD_SUBDIRECTORY(example)
ADD_SUBDIRECTORY(python)
ADD_SUBDIRECTORY(test-suite)
In ./src, I find boost components except the unit_test_framework.
FIND_PACKAGE(Boost REQUIRED COMPONENTS regex program_options filesystem system)
IF(Boost_FOUND)
add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})
MESSAGE(STATUS Boost: ${Boost_LIBRARIES})
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
ENDIF()
in ./test-suite, It is:
UNSET(Boost_LIBRARIES)
SET(Boost_USE_STATIC_LIBS OFF)
IF(UNIX)
SET(Boost_USE_MULTITHREADED OFF)
ENDIF(UNIX)
find_package(Boost REQUIRED COMPONENTS unit_test_framework)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS} ${GSL_INCLUDE_DIR})
# here is the unit-test executable
TARGET_LINK_LIBRARIES(utest tesla-static glps-static
${Boost_LIBRARIES} hdf5_hl hdf5 ${Boost_REGEX_LIBRARY} )
SET_TARGET_PROPERTIES(utest PROPERTIES COMPILE_FLAGS
-DBOOST_TEST_DYN_LINK ${Boost_UNIT_TEST_FRAMEWORK_DYN_LINK})
IF(WIN32)
SET_TARGET_PROPERTIES(utest PROPERTIES COMPILE_FLAGS
-DBOOST_ALL_NO_LIB -DBOOST_TEST_DYN_LINK
${Boost_UNIT_TEST_FRAMEWORK_DYN_LINK}
${Boost_LIB_DIAGNOSTIC_DEFINITIONS})
ENDIF(WIN32)
Thanks.
Forest
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
He probably just uses a project.vcproj.user file, and uses the configure_file() command on it to fill in command arguments, environment variables, etc etc. I've done this before and it works fantastically, although I have never tried it to force the EXE to search for my DLL files without copying them. Good idea though, if it works! - Robert Dailey On Tue, Jan 10, 2012 at 2:29 PM, Michael Jackson mike.jack...@bluequartz.net wrote: I am VERY interested in how you did this. Did you have CMake write a file for you? Do you have some code to share by any chance? Thanks -- Mike Jackson www.bluequartz.net On Jan 10, 2012, at 3:17 PM, Ben Medina wrote: I'd guess the performance of fixup_bundle will be a big pitfall if you're planning on doing this after every build. An entirely different approach is to configure a Visual Studio .user file to set the PATH environment variable (not setting it globally; just for debugging your app from within VS). You still have to track which directories to add to the PATH, but this approach has worked flawlessly for us (across multiple versions of VS, as well as 32- and 64-bit configs). On Mon, Jan 9, 2012 at 8:41 AM, David Cole david.c...@kitware.com wrote: 2012/1/9 Hauke Heibel hauke.hei...@googlemail.com: 2012/1/9 Michael Stürmer m.stuer...@pmdtec.com: Awesome! Sometimes you just need to know what's already available to solve your problems in a very elegant way. I'll have a look at these bundles and probably switch to them instead of maintaining my own stuff! When looking at the initial problem, I am pretty much convinced that you need a combination of your own script and GetPrerequisites since you want to copy to your run-time output directory - and there to specific sub-directories depending on the build type. It may well be that I have overseen some functionality in those new modules ... - Hauke BundleUtilities, on Windows, should copy dlls to be in the same directory as the executable being analyzed... So, as long as the exe is in the right directory when fixup_bundle is called on it, then the dlls will get copied into that same directory. Cheers, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack output name using VS IDE
2012/1/11 Totte Karlsson to...@dunescientific.com: cmake --help-variable CMAKE_CFG_INTDIR When executing the PACKAGE target from the IDE, that variable is evaluated to $(Configuration) Not quite. CMake evaluates it to $(Configuration) (or what ever the particular IDE uses), which then gets expanded by the IDE to the current configuration, i.e. Debug, Release, etc. In the PACKAGE target it does not seem to get expanded. Any idea how to 'force' such thing. Yes it should be. The trouble is this is not evaluated at but at CMake time when include(CPack) is processed. Then at CPack time the value is read from within cpack command so that it is not evaluated either. That's why I said: You may probably hand-craft you own custom_command/target for that but don't know how to add this to the built-in PACKAGE target. I'm not using Visual Studio on a daily basis and I cannot test the scheme right now but may be other can. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2042-g30a3a1a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 30a3a1a72bd745ac7da3c9d5f91894eab3d7b9e6 (commit)
via a04ced3b38cc1ac7903a219c8abc9e31dfe5fbe8 (commit)
from 4045f5a1d2360f22f05a8b2894978839656d8409 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30a3a1a72bd745ac7da3c9d5f91894eab3d7b9e6
commit 30a3a1a72bd745ac7da3c9d5f91894eab3d7b9e6
Merge: 4045f5a a04ced3
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jan 10 09:59:55 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jan 10 09:59:55 2012 -0500
Merge topic 'FindPythonLibs-single-user-issue-12869' into next
a04ced3 FindPythonLibs: Search for single-user installs on Windows
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a04ced3b38cc1ac7903a219c8abc9e31dfe5fbe8
commit a04ced3b38cc1ac7903a219c8abc9e31dfe5fbe8
Author: Christian Andersson ch...@maths.lth.se
AuthorDate: Tue Jan 10 09:55:42 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Jan 10 09:58:43 2012 -0500
FindPythonLibs: Search for single-user installs on Windows
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.
diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index adcec46..da7a1ac 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -40,13 +40,17 @@ FOREACH(_CURRENT_VERSION ${_Python_VERSIONS})
NAMES python${_CURRENT_VERSION_NO_DOTS}_d python
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs/Debug
-
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
)
+
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs/Debug
+
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
+
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
+ )
ENDIF(WIN32)
FIND_LIBRARY(PYTHON_LIBRARY
NAMES python${_CURRENT_VERSION_NO_DOTS} python${_CURRENT_VERSION}
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
+
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
# Avoid finding the .dll in the PATH. We want the .lib.
NO_SYSTEM_ENVIRONMENT_PATH
)
@@ -79,6 +83,7 @@ FOREACH(_CURRENT_VERSION ${_Python_VERSIONS})
PATHS
${PYTHON_FRAMEWORK_INCLUDES}
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
+
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
PATH_SUFFIXES
python${_CURRENT_VERSION}
)
---
Summary of changes:
Modules/FindPythonLibs.cmake |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-2050-g0a74992
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0a749924cd46219f79af554d57001bafce3a6f61 (commit)
via a55940cccd379bf3f7feaf562e082242d84d6458 (commit)
from 231a2b784fe71b6a42d574c7f867ff53230acd43 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a749924cd46219f79af554d57001bafce3a6f61
commit 0a749924cd46219f79af554d57001bafce3a6f61
Merge: 231a2b7 a55940c
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Jan 10 13:28:51 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jan 10 13:28:51 2012 -0500
Merge topic 'test-symbol-exists' into next
a55940c CheckCXXSymbolExists: catch compilers where errno is not in
namespace std
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a55940cccd379bf3f7feaf562e082242d84d6458
commit a55940cccd379bf3f7feaf562e082242d84d6458
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Jan 10 19:23:56 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Tue Jan 10 19:23:56 2012 +0100
CheckCXXSymbolExists: catch compilers where errno is not in namespace std
Looks like MIPSpro on IRIX and MSVC6 get this wrong.
diff --git a/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
b/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
index c55c05d..d69e167 100644
--- a/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
+++ b/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
@@ -65,6 +65,14 @@ IF (CMAKE_COMPILER_IS_GNUCXX)
ENDIF (CSE_RESULT_O3)
ENDIF (CMAKE_COMPILER_IS_GNUCXX)
+IF(CMAKE_CXX_COMPILER_ID IS MIPSpro)
+ SET(NO_STD_NAMESPACE_FOR_ERRNO TRUE)
+ELSEIF(MSVC_VERSION AND NOT MSVC_VERSION VERSION_GREATER 1200)
+ SET(NO_STD_NAMESPACE_FOR_ERRNO TRUE)
+ELSE()
+ SET(NO_STD_NAMESPACE_FOR_ERRNO FALSE)
+ENDIF()
+
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/errno.cxx.in
${CMAKE_CURRENT_BINARY_DIR}/errno.cxx @ONLY)
add_executable(CheckCXXSymbolExists ${CMAKE_CURRENT_BINARY_DIR}/errno.cxx)
diff --git a/Tests/Module/CheckCXXSymbolExists/errno.cxx.in
b/Tests/Module/CheckCXXSymbolExists/errno.cxx.in
index 81b51aa..bd955a9 100644
--- a/Tests/Module/CheckCXXSymbolExists/errno.cxx.in
+++ b/Tests/Module/CheckCXXSymbolExists/errno.cxx.in
@@ -10,7 +10,13 @@
// This is required for the Borland compiler, but should be right for all
// others, too. To avoid breaking older compilers we don't simply use
// std::errno.
+
+#cmakedefine NO_STD_NAMESPACE_FOR_ERRNO
+
+#if !defined(NO_STD_NAMESPACE_FOR_ERRNO)
+// but of course there are compilers where this doesn't work
using namespace std;
+#endif
int main()
{
---
Summary of changes:
Tests/Module/CheckCXXSymbolExists/CMakeLists.txt |8
Tests/Module/CheckCXXSymbolExists/errno.cxx.in |6 ++
2 files changed, 14 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-2053-g2833585
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 283358528a4600dfcca08df7338cc10588b3c532 (commit) via 0df1942a72f1e67c88f0d02dc405fbd76793347a (commit) via a5e892ca1fbcbeefbe080305aa847d35bd7f930a (commit) from 0a749924cd46219f79af554d57001bafce3a6f61 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=283358528a4600dfcca08df7338cc10588b3c532 commit 283358528a4600dfcca08df7338cc10588b3c532 Merge: 0a74992 0df1942 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jan 10 13:34:18 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Jan 10 13:34:18 2012 -0500 Merge topic 'compiler-version' into next 0df1942 Detect SGI MIPSpro compiler version with its id a5e892c Document compiler version macro formats used for detection http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0df1942a72f1e67c88f0d02dc405fbd76793347a commit 0df1942a72f1e67c88f0d02dc405fbd76793347a Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jan 10 13:29:39 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jan 10 13:29:39 2012 -0500 Detect SGI MIPSpro compiler version with its id Decode decimal digits from _SGI_COMPILER_VERSION or _COMPILER_VERSION to compute version number components. See documentation at: http://predef.sourceforge.net/precomp.html diff --git a/Modules/CMakeCCompilerId.c.in b/Modules/CMakeCCompilerId.c.in index 9e12ec5..5ed8d82 100644 --- a/Modules/CMakeCCompilerId.c.in +++ b/Modules/CMakeCCompilerId.c.in @@ -141,6 +141,17 @@ #elif defined(_SGI_COMPILER_VERSION) || defined(_COMPILER_VERSION) # define COMPILER_ID MIPSpro +# if defined(_SGI_COMPILER_VERSION) + /* _SGI_COMPILER_VERSION = VRP */ +# define COMPILER_VERSION_MAJOR DEC(_SGI_COMPILER_VERSION/100) +# define COMPILER_VERSION_MINOR DEC(_SGI_COMPILER_VERSION/10 % 10) +# define COMPILER_VERSION_PATCH DEC(_SGI_COMPILER_VERSION% 10) +# else + /* _COMPILER_VERSION = VRP */ +# define COMPILER_VERSION_MAJOR DEC(_COMPILER_VERSION/100) +# define COMPILER_VERSION_MINOR DEC(_COMPILER_VERSION/10 % 10) +# define COMPILER_VERSION_PATCH DEC(_COMPILER_VERSION% 10) +# endif /* This compiler is either not known or is too old to define an identification macro. Try to identify the platform and guess that diff --git a/Modules/CMakeCXXCompilerId.cpp.in b/Modules/CMakeCXXCompilerId.cpp.in index dc3f1d7..927f7f4 100644 --- a/Modules/CMakeCXXCompilerId.cpp.in +++ b/Modules/CMakeCXXCompilerId.cpp.in @@ -132,6 +132,17 @@ #elif defined(_SGI_COMPILER_VERSION) || defined(_COMPILER_VERSION) # define COMPILER_ID MIPSpro +# if defined(_SGI_COMPILER_VERSION) + /* _SGI_COMPILER_VERSION = VRP */ +# define COMPILER_VERSION_MAJOR DEC(_SGI_COMPILER_VERSION/100) +# define COMPILER_VERSION_MINOR DEC(_SGI_COMPILER_VERSION/10 % 10) +# define COMPILER_VERSION_PATCH DEC(_SGI_COMPILER_VERSION% 10) +# else + /* _COMPILER_VERSION = VRP */ +# define COMPILER_VERSION_MAJOR DEC(_COMPILER_VERSION/100) +# define COMPILER_VERSION_MINOR DEC(_COMPILER_VERSION/10 % 10) +# define COMPILER_VERSION_PATCH DEC(_COMPILER_VERSION% 10) +# endif /* This compiler is either not known or is too old to define an identification macro. Try to identify the platform and guess that http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a5e892ca1fbcbeefbe080305aa847d35bd7f930a commit a5e892ca1fbcbeefbe080305aa847d35bd7f930a Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jan 10 13:22:15 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jan 10 13:24:38 2012 -0500 Document compiler version macro formats used for detection 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. diff --git a/Modules/CMakeCCompilerId.c.in b/Modules/CMakeCCompilerId.c.in index c39eccb..9e12ec5 100644 --- a/Modules/CMakeCCompilerId.c.in +++ b/Modules/CMakeCCompilerId.c.in @@ -2,16 +2,21 @@ # error A C++ compiler has been selected for C. #endif +/* Version number components: V=Version, R=Revision, P=Patch + Version date components: =Year, MM=Month, DD=Day */ + #if defined(__18CXX) # define ID_VOID_MAIN #endif #if defined(__INTEL_COMPILER) || defined(__ICC) # define COMPILER_ID Intel + /* __INTEL_COMPILER = VRP */ # define COMPILER_VERSION_MAJOR DEC(__INTEL_COMPILER/100) # define COMPILER_VERSION_MINOR DEC(__INTEL_COMPILER/10 % 10) # define COMPILER_VERSION_PATCH
