Re: [CMake] How to find/run external host executables when using cross compiling
On 12/4/13, Eric Wing wrote: > I'm currently trying to port a rather large, complex project to > Android. It has an existing CMake project so I'm trying to leverage > that. I've taken and enhanced one of the Android-CMake toolchains I've > found. > > This particular project I'm porting has unfortunate dependencies on > running the host system's Perl, Python, and Ruby interpreters to do > various kinds of on-the-fly code generation. > > The problem I'm having is that with the cross-compilation toolchain, > none of these (host) dependencies are found with CMake (I think it > uses FindPackage) because the cross-compilation toolchain has > sandboxed off everything to look in the target toolchain which won't > have Perl/Python/Ruby (which is completely reasonable; I'm not > complaining). > > But I need to solve this problem and figure out how to find/invoke the > host Perl/Python/Ruby/etc so my cross-compile can work. > > Can anybody give me suggestions on how I should approach this? Bump. I have a temporary workaround in place where I comment out the find_package calls for Perl/Python/Ruby, and then use -D switches with CMake to pre-populate the correct values for my host system. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Windows XP + CMake + VS2013
Hi Stefan, You should add CMake command option *-T vc120_xp* BR, Andrey Upadyshev On Sun, Dec 8, 2013 at 7:22 PM, Stefan Fendt wrote: > Hi, > > I'm using CMake 2.8.12 together with MSVC 2013 and need to produce a > binary which is (still) compatible with Windows XP SP3. > If I'm right, then I need to change the compiler toolchain to 120_xp to > make this work (I get the message that the binary isn't a valid > WIN32-application on the XP machine otherwise). How am I supposed to tell > CMake to use this compiler toolchain? > > With best regards, > Stefan > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Building Matlab MEX files - a solution?
I've been working on a project which requires building. After coming up
with a brittle, overcomplicated way to use Matlab's MEX script to compile
mex files, it occurred to me that I could simplify things by using the
output of the MEX script.
To that end, I wrote this. It seems to work great on Linux and OS X. I
don't have an easy way to try it on Windows; I'd love to hear from someone
who could try it. This only works with a customized
version of FindMatlab.cmake, also included here.
BuildMex.cmake-
# BuildMex.cmake
# Author: Kent Williams norman-k-willi...@uiowa.edu
include(CMakeParseArguments)
if(NOT MATLAB_FOUND)
find_package(MATLAB REQUIRED)
endif()
# CMake 2.8.12 & earlier apparently don't define the
# Mex script path, so find it.
if(NOT MATLAB_MEX_PATH)
find_program( MATLAB_MEX_PATH mex
HINTS ${MATLAB_ROOT}/bin
PATHS ${MATLAB_ROOT}/bin
DOC "The mex program path"
)
if(NOT MATLAB_MEX_PATH)
message(FATAL_ERROR "Can't find Matlab MEX compiler")
endif()
endif()
include_directories(${MATLAB_INCLUDE_DIR})
#
# mex -v outputs all the settings used for building MEX files, so it
# we can use it to grab the important variables needed to generate
# a well formed mex file.
execute_process(COMMAND ${MATLAB_MEX_PATH} -v
OUTPUT_VARIABLE mexOut
ERROR_VARIABLE mexErr)
# parse mex output line by line by turning file into CMake list of lines
string(REGEX REPLACE "\r?\n" ";" _mexOut "${mexOut}")
foreach(line ${_mexOut}) if("${line}" MATCHES " CXXFLAGS *=")
string(REGEX REPLACE " *CXXFLAGS *= *" "" mexCxxFlags "${line}")
elseif("${line}" MATCHES " CXXLIBS *=")
string(REGEX REPLACE " *CXXLIBS *= *" "" mexCxxLibs "${line}")
elseif("${line}" MATCHES " LDFLAGS *=")
string(REGEX REPLACE " *LDFLAGS *= *" "" mexLdFlags "${line}")
elseif("${line}" MATCHES " LDEXTENSION *=")
string(REGEX REPLACE " *LDEXTENSION *= *" "" mexLdExtension "${line}")
endif()
endforeach()
list(APPEND mexCxxFlags "-DMATLAB_MEX_FILE")
#
# BuildMex -- arguments
# MEXNAME = root of mex library name
# TARGETDIR = location for the mex library files to be created
# SOURCE = list of source files
# LIBRARIES = libraries needed to link mex library
macro(BuildMex)
set(oneValueArgs MEXNAME TARGETDIR)
set(multiValueArgs SOURCE LIBRARIES)
cmake_parse_arguments(BuildMex "" "${oneValueArgs}" "${multiValueArgs}"
${ARGN})
set_source_files_properties(${BuildMex_SOURCE}COMPILE_DEFINITIONS
${mexCxxFlags}
)
add_library(${BuildMex_MEXNAME} SHARED ${BuildMex_SOURCE})
set_target_properties(${BuildMex_MEXNAME} PROPERTIES
SUFFIX "${mexLdExtension}"
RUNTIME_OUTPUT_DIRECTORY "${BuildMex_TARGETDIR}"
ARCHIVE_OUTPUT_DIRECTORY "${BuildMex_TARGETDIR}"
LIBRARY_OUTPUT_DIRECTORY "${BuildMex_TARGETDIR}"
)
target_link_libraries(${BuildMex_MEXNAME} ${BuildMex_LIBRARIES}
${mexCxxLibs})
endmacro(BuildMex)
FindMatlab.cmake
# - this module looks for Matlab
# Defines:
# MATLAB_INCLUDE_DIR: include path for mex.h, engine.h
# MATLAB_LIBRARIES: required libraries: libmex, etc
# MATLAB_MEX_LIBRARY: path to libmex.lib
# MATLAB_MX_LIBRARY: path to libmx.lib
# MATLAB_MAT_LIBRARY: path to libmat.lib # added
# MATLAB_ENG_LIBRARY: path to libeng.lib
# MATLAB_ROOT: path to Matlab's root directory
# This file is part of Gerardus
#
# This is a derivative work of file FindMatlab.cmake released with
# CMake v2.8, because the original seems to be a bit outdated and
# doesn't work with my Windows XP and Visual Studio 10 install
#
# (Note that the original file does work for Ubuntu Natty)
#
# Author: Ramon Casero , Tom Doel
# Version: 0.2.3
# $Rev$
# $Date$
#
# The original file was copied from an Ubuntu Linux install
# /usr/share/cmake-2.8/Modules/FindMatlab.cmake
#==
===
# Copyright 2005-2009 Kitware, Inc.
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#==
===
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
set(MATLAB_FOUND 0)
if(WIN32)
# Search for a version of Matlab available, starting from the most
modern one to older versions
foreach(MATVER "7.14" "7.11" "7.10" "7.9" "7.8" "7.7" "7.6" "7.5" "7.4")
if((NOT DEFINED MATLAB_ROOT)
OR ("${MATLAB_ROOT}" STREQUAL "")
OR ("${MATLAB_ROOT}" STREQUAL "/registry"))
get_filename_component(MATLAB_ROOT
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\MathWorks\\MATLAB\\${MATVER};MATLABROOT]"
ABSOLUTE)
set(MATLAB_VERSION ${MATVER})
endif()
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
On Mon, Dec 9, 2013 at 4:52 PM, Andreas Pakulat wrote: > Hi, > > On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec wrote: >> >> Dear list members, >> >> I often like or need to install two versions of the same software. >> Ideally the software should put its files by default to >> $prefix/include/$NAME/*.h >> $prefix/lib/$NAME/*.dylib >> ... >> ($prefix => $CMAKE_INSTALL_PREFIX) >> >> and in order to be able to install multiple versions side-by-side I >> would like to be able to specify something like >> -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION >> -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION >> to end up with >> $prefix/include/$NAME/$VERSION/*.h >> $prefix/lib/$NAME/$VERSION/*.dylib >> instead of default paths. > > > Do you have any reasons that speak against using separate prefixes for each > version of that software? First, both versions of the software *have to* to be installed under $prefix (in my case that is usually /opt/local) because that is the location where all the packages installed by a specific package manager (MacPorts) need to end up. What I could do is to install the two versions under CMAKE_INSTALL_PREFIX=$prefix/Library/Frameworks/$NAME.framework/Versions/$VERSION/ even if the software doesn't really satisfy the layout of a framework, but that layout doesn't really simplify that much other than no need to specify 5 separate variables to change include, lib, man, doc, ... > In particular since such a setup will make your > life harder when you want to use the installed software in some cmake-based > project. That's not a really good argument. Life is already hard. For FindX11 I need to manually specify about 20 different variables to be able to get rid of searching in /usr/X11R6 (Mac OS X) for example and use the libraries from /opt/local instead. For almost any given library I usually need to specify 2-5 variables (one for includes and several for each single dylib) and a lot of FindWhatever.cmake are simply too "stupid" to allow easy configuration. The pkg-config approach works a whole lot better in a lot of cases. I would really like to avoid searching in some prefixes (for example I would like to avoid searching for libraries in /usr/local and only search in /opt/local), but I don't know any elegant way to do so. And in case of some specific software I have in mind, the software itself provides its own CMake configuration file, so all dependent packages/software need to do is to find that configuration file, nothing else. > In that case you'd have to manually specify include-dir and lib-dir > when configuring the project since many find-modules simply expect a > 'standard' unix-like layout below the prefix under which they should search > for a given software. So they don't look into include/ or > lib/ so you'd need to specify that manually. Compared with the ease > of just specifying CMAKE_PREFIX_PATH to the installation directory for the > version you want thats a lot more effort each time you setup a build > directory. I'm still interested in the answer to my original question and would like to avoid discussion about why not specifying a different $prefix. There are surely many pros and contras to each approach and it makes no sense to get off-topic with a different discussion. (I could surely write an essay about pros of my approach, but that wouldn't help me answer my question. I can open a new thread about that if needed, but let's stick to the original question here.) Mojca -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
Hi, On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec < mojca.miklavec.li...@gmail.com> wrote: > Dear list members, > > I often like or need to install two versions of the same software. > Ideally the software should put its files by default to > $prefix/include/$NAME/*.h > $prefix/lib/$NAME/*.dylib > ... > ($prefix => $CMAKE_INSTALL_PREFIX) > > and in order to be able to install multiple versions side-by-side I > would like to be able to specify something like > -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION > -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION > to end up with > $prefix/include/$NAME/$VERSION/*.h > $prefix/lib/$NAME/$VERSION/*.dylib > instead of default paths. > Do you have any reasons that speak against using separate prefixes for each version of that software? In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/ or lib/ so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix => $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. The problem is that in this case either of the two options must be true: a) Software sets CMAKE_INSTALL_INCLUDEDIR to "include/$NAME" rather than to "include" by default which "violates" the convention from http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs, but leads to the desired behaviour. b) Software sets CMAKE_INSTALL_INCLUDEDIR to "include" by default and automatically adds "$NAME" to an internal variable when installing the files. The drawback of this approach is that -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION results in files being installed to $prefix/include/$NAME/$VERSION/$NAME/*.h and there is absolutely no way to change that. What approach would you suggest to achieve the desired behaviour without violating the conventions? Thank you very much, Mojca -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag - solved
On 12/9/2013 2:34 PM, Eric Noulard wrote: 2013/12/9 pellegrini : Thanks Eric for the hint. I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable but unfortunately, in the present case, the problem is a bit different. It can be for example that on a 64 bit machine, I would like to use the 32 bit ifort version because the only version of Winteracter library I have is the 32 bit one. That's why I came to the point that the only way to proceed was through a cmake option. I could also try to guess the kind of build I would like from the path of my compiler but this approach seems quite restrictive and especially hazardous ... This shouldn't be true. the value of CMAKE_SIZEOF_VOID_P should follow the capacity of the **compiler** used and not the capacity of the host. It works for cross-compiling as well. e.g. when I cross compile to Win32 on my Linux 64 bits host CMAKE_SIZEOF_VOID_P is equal to 4 i.e. 32 bits. In your case you are on 64 bit Windows host but you compile your program using a 32 bits compiler, this should work. The easiest way to check what happen is to try to print the value of CMAKE_SIZEOF_VOID_P in yor case. Hi Eric, just put your snippet in a macros and everything worked fine: I could "guess" the architecture properly. That's for sure from far the best way to get rid of my architecture "problem". thanks a lot Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
2013/12/9 pellegrini : >> >> > Thanks Eric for the hint. > I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable but > unfortunately, in the present case, > the problem is a bit different. It can be for example that on a 64 bit > machine, I would like to use the 32 bit > ifort version because the only version of Winteracter library I have is the > 32 bit one. That's why I came to the point > that the only way to proceed was through a cmake option. I could also try to > guess the kind of build I would like from > the path of my compiler but this approach seems quite restrictive and > especially hazardous ... This shouldn't be true. the value of CMAKE_SIZEOF_VOID_P should follow the capacity of the **compiler** used and not the capacity of the host. It works for cross-compiling as well. e.g. when I cross compile to Win32 on my Linux 64 bits host CMAKE_SIZEOF_VOID_P is equal to 4 i.e. 32 bits. In your case you are on 64 bit Windows host but you compile your program using a 32 bits compiler, this should work. The easiest way to check what happen is to try to print the value of CMAKE_SIZEOF_VOID_P in yor case. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
On 12/9/2013 1:26 PM, Eric Noulard wrote:
2013/12/9 pellegrini :
Dear CMakers,
I have to build cmake files for a Fortran project using ifort compiler on
Windows, linux and macos platform.
That project will be linked to Winteracter Fortran library whose
installation paths are different depending on the 32
or 64 bit versions. Is there a way to automatically detect whether the build
is a 32 bit or 64 bit one in order to define
the correct path for Winteracter library ? Up to now, the only way I found
to do this was by introducing a cmake
option to my build (ON for 64bit build and OFF for a 32 one). I also saw the
CMAKE_CL_64 flag that could have been
interesting but unfortunately it is only for microsoft.
Usually you chekc the value of CMAKE_SIZEOF_VOID_P
which will be 8 on 64 bits system and 4 on 32 bits ones.
e.g. here is what I use:
# Test 32/64 bits
if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
message(STATUS "Target is 64 bits")
if (WIN32)
set(WINXXBITS Win64)
endif(WIN32)
else("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
message(STATUS "Target is 32 bits")
if (WIN32)
set(WINXXBITS Win32)
endif(WIN32)
endif("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
See:
http://www.cmake.org/pipermail/cmake/2011-February/042752.html
or
cmake --help-variable CMAKE_SIZEOF_VOID_P
thanks for your help
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Thanks Eric for the hint.
I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable
but unfortunately, in the present case,
the problem is a bit different. It can be for example that on a 64 bit
machine, I would like to use the 32 bit
ifort version because the only version of Winteracter library I have is
the 32 bit one. That's why I came to the point
that the only way to proceed was through a cmake option. I could also
try to guess the kind of build I would like from
the path of my compiler but this approach seems quite restrictive and
especially hazardous ...
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
2013/12/9 pellegrini :
> Dear CMakers,
>
> I have to build cmake files for a Fortran project using ifort compiler on
> Windows, linux and macos platform.
> That project will be linked to Winteracter Fortran library whose
> installation paths are different depending on the 32
> or 64 bit versions. Is there a way to automatically detect whether the build
> is a 32 bit or 64 bit one in order to define
> the correct path for Winteracter library ? Up to now, the only way I found
> to do this was by introducing a cmake
> option to my build (ON for 64bit build and OFF for a 32 one). I also saw the
> CMAKE_CL_64 flag that could have been
> interesting but unfortunately it is only for microsoft.
Usually you chekc the value of CMAKE_SIZEOF_VOID_P
which will be 8 on 64 bits system and 4 on 32 bits ones.
e.g. here is what I use:
# Test 32/64 bits
if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
message(STATUS "Target is 64 bits")
if (WIN32)
set(WINXXBITS Win64)
endif(WIN32)
else("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
message(STATUS "Target is 32 bits")
if (WIN32)
set(WINXXBITS Win32)
endif(WIN32)
endif("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
See:
http://www.cmake.org/pipermail/cmake/2011-February/042752.html
or
cmake --help-variable CMAKE_SIZEOF_VOID_P
>
> thanks for your help
>
> Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] 32/64 bit flag
Dear CMakers, I have to build cmake files for a Fortran project using ifort compiler on Windows, linux and macos platform. That project will be linked to Winteracter Fortran library whose installation paths are different depending on the 32 or 64 bit versions. Is there a way to automatically detect whether the build is a 32 bit or 64 bit one in order to define the correct path for Winteracter library ? Up to now, the only way I found to do this was by introducing a cmake option to my build (ON for 64bit build and OFF for a 32 one). I also saw the CMAKE_CL_64 flag that could have been interesting but unfortunately it is only for microsoft. thanks for your help Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE] Getting compilation date through CMake
Thanks for the tip Jakub.
BTW, I just realized that the
[OUTPUT_STRIP_TRAILING_WHITESPACE]
option of EXECUTE_PROCESS has the same effect of the regex I wrote to strip
the trailing linebreaks.
Regards,
JON HAITZ
On 9 December 2013 09:46, Jakub Zakrzewski wrote:
> Hi,
> I only wanted to warn you, that windows "date" command output is
> locale-specific, so you may get into trouble if you want to use it as
> anything else than a string literal.
>
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
> Of Jon Haitz Legarreta
> Sent: Montag, 9. Dezember 2013 09:01
> To: Matthew Woehlke
> Cc: cmake@cmake.org
> Subject: Re: [CMake] [CMAKE] Getting compilation date through CMake
>
> BTW, just for other newbies, I think my mistake was that I took another
> external command example literally:
>
> EXECUTE_PROCESS(
> COMMAND
> svnversion -nc "${sourceDir}"
> OUTPUT_VARIABLE _out_svnversion
> )
> Now I guess the above works (without invoking the command prompt) because
> a FindSubversion.cmake exists in CMake, and there is an svnversion.exe
> somewhere in my SVN install.
>
> HTH,
> JON HAITZ
>
> On 9 December 2013 08:53, Jon Haitz Legarreta
> wrote:
> Dear Fraser and Matthew,
> yes, both approaches work. Thank you.
>
> There seems to be a trailing endline in the response given by
> $ENV{COMSPEC} /c date /t, so the following regex helps deleting it:
>
> STRING(REGEX REPLACE "(\r?\n)+$" "" _date "${_date}")
> Thanks again,
> JON HAITZ
>
>
>
> On 5 December 2013 22:34, Matthew Woehlke
> wrote:
> On 2013-12-05 15:46, Fraser Hutchison wrote:
> If you can specify CMake version 2.8.11 as a minimum, you could use
> the string(TIMESTAMP ...) command instead:
>
> string(TIMESTAMP _output "%d/%m/%Y")
>
> Bear in mind that these only execute when CMake runs (i.e. at configure
> time)
> rather than at build time, so strictly-speaking you're not actually
> grabbing the
> compile date.
>
> Of course you could put that in a CMake script and execute it with e.g.
> '${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a
> custom command :-). Then it would truly be the compile date. (Needless to
> say, the script would need to write the date into some generated source
> file, e.g. with configure_file.)
>
> --
> Matthew
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE] Getting compilation date through CMake
Hi,
I only wanted to warn you, that windows "date" command output is
locale-specific, so you may get into trouble if you want to use it as anything
else than a string literal.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Jon
Haitz Legarreta
Sent: Montag, 9. Dezember 2013 09:01
To: Matthew Woehlke
Cc: cmake@cmake.org
Subject: Re: [CMake] [CMAKE] Getting compilation date through CMake
BTW, just for other newbies, I think my mistake was that I took another
external command example literally:
EXECUTE_PROCESS(
COMMAND
svnversion -nc "${sourceDir}"
OUTPUT_VARIABLE _out_svnversion
)
Now I guess the above works (without invoking the command prompt) because a
FindSubversion.cmake exists in CMake, and there is an svnversion.exe somewhere
in my SVN install.
HTH,
JON HAITZ
On 9 December 2013 08:53, Jon Haitz Legarreta wrote:
Dear Fraser and Matthew,
yes, both approaches work. Thank you.
There seems to be a trailing endline in the response given by $ENV{COMSPEC} /c
date /t, so the following regex helps deleting it:
STRING(REGEX REPLACE "(\r?\n)+$" "" _date "${_date}")
Thanks again,
JON HAITZ
On 5 December 2013 22:34, Matthew Woehlke wrote:
On 2013-12-05 15:46, Fraser Hutchison wrote:
If you can specify CMake version 2.8.11 as a minimum, you could use
the string(TIMESTAMP ...) command instead:
string(TIMESTAMP _output "%d/%m/%Y")
Bear in mind that these only execute when CMake runs (i.e. at configure time)
rather than at build time, so strictly-speaking you're not actually grabbing the
compile date.
Of course you could put that in a CMake script and execute it with e.g.
'${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a custom
command :-). Then it would truly be the compile date. (Needless to say, the
script would need to write the date into some generated source file, e.g. with
configure_file.)
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE] Getting compilation date through CMake
BTW, just for other newbies, I think my mistake was that I took another
external command example literally:
EXECUTE_PROCESS(
COMMAND
svnversion -nc "${sourceDir}"
OUTPUT_VARIABLE _out_svnversion
)
Now I guess the above works (without invoking the command prompt) because a
FindSubversion.cmake exists in CMake, and there is an svnversion.exe
somewhere in my SVN install.
HTH,
JON HAITZ
On 9 December 2013 08:53, Jon Haitz Legarreta wrote:
> Dear Fraser and Matthew,
> yes, both approaches work. Thank you.
>
> There seems to be a trailing endline in the response given by
> $ENV{COMSPEC} /c date /t, so the following regex helps deleting it:
>
> STRING(REGEX REPLACE "(\r?\n)+$" "" _date "${_date}")
>
> Thanks again,
> JON HAITZ
>
>
>
>
> On 5 December 2013 22:34, Matthew Woehlke wrote:
>
>> On 2013-12-05 15:46, Fraser Hutchison wrote:
>>
>>> If you can specify CMake version 2.8.11 as a minimum, you could use
>>> the string(TIMESTAMP ...) command instead:
>>>
>>> string(TIMESTAMP _output "%d/%m/%Y")
>>>
>>> Bear in mind that these only execute when CMake runs (i.e. at configure
>>> time)
>>> rather than at build time, so strictly-speaking you're not actually
>>> grabbing the
>>> compile date.
>>>
>>
>> Of course you could put that in a CMake script and execute it with e.g.
>> '${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a
>> custom command :-). Then it would truly be the compile date. (Needless to
>> say, the script would need to write the date into some generated source
>> file, e.g. with configure_file.)
>>
>> --
>> Matthew
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/
>> opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
