[CMake] cpack and boost dependencies when building a debian installer
Hello everybody,
I would like to use cpack (2.8.7) in order to build a debian installer
for a c++ library that has a few dependencies namely:
- boost (headers + libraries)
- fftw3-3
- eigen3
- hdf5
- tiff
I would like to set my cpack file in such a way that the minimum version
required for boost is the 1.54. So I introduced in my cmake/cpack
file the following command according to my understanding of CPACK
documentation.
set(BOOST_MIN_VERSION 1.54)
string(REPLACE , , CPACK_DEBIAN_PACKAGE_DEPENDS
libboost-all-dev (= ${BOOST_MIN_VERSION}),
libeigen3-dev,
libfftw3-3,
libtiff4-dev,
libhdf5-serial-dev,)
Once my debian file is created, I get the following error when launching
it with gdebi (but also with dpkg):
##
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done
Building data structures... Done
This package is uninstallable
Dependency is not satisfiable: libboost-all-dev (= 1.54)
##
However, boost is actually installed on my machine (version 1.55.0). Did
I misunderstand something in the way to declare that
we need a minimum version for a given library ?
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://public.kitware.com/mailman/listinfo/cmake
[CMake] question about SET_SOURCE_FILES_PROPERTIES
Dear CMakers,
I have a Fortran project to be built on Windows and Linux using ifort
compiler. For two of the project files, I need to add
specific compiler flag (i.e. /assume:byterecl). To do so, I used the
following CMake command:
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS} /assume:byterecl)
There is one point I could not make clear up to now: if I want this
extra flag to be used whatever the
CMAKE_BUILD_TYPE, is the above command sufficient ? By sufficient I mean
will the use of
${CMAKE_Fortran_FLAGS} be spread all over the
${CMAKE_Fortran_FLAGS_DEBUG}, ${CMAKE_Fortran_FLAGS_RELEASE} ... flags ?
I would like to avoid something like:
IF(CMAKE_BUILD_TYPE STREQUAL Debug)
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS_DEBUG} /assume:byterecl)
ELSEIF(CMAKE_BUILD_TYPE STREQUAL Release)
SET_SOURCE_FILES_PROPERTIES(file1.f90 PROPERTIES COMPILE_FLAGS
${CMAKE_Fortran_FLAGS_RELEASE} /assume:byterecl)
... and so on for the other build type. Not very nice isn't it but do I
have the choice ?
thanks a lot 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
[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] 32/64 bit flag
On 12/9/2013 1:26 PM, Eric Noulard wrote:
2013/12/9 pellegrini pellegr...@ill.fr:
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 - solved
On 12/9/2013 2:34 PM, Eric Noulard wrote: 2013/12/9 pellegrini pellegr...@ill.fr: 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
[CMake] problem with shortcut CPACK/NSIS
Dear all,
I know that this issue has been raised several times but all the
solution I tried failed up to now.
We have a Fortran 90 project for which we would like to create a NSIS
installer using CPACK. When installing the software
we would like:
- the PATH to be updated with the installation path
- to set another environment variable called SXTALSOFTSUITE
- create desktop and SMP shortcuts
All the trials we did up to now to create the SXTALSOFTSUITE failed even
when using the command:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS WriteRegStr HKCU 'Environment'
'SXTALSOFTSUITE' '$INSTDIR')
All the trials we did to update the path failed even when using:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS Push 'PATH'
Push 'A'
Push 'HKCU'
Push '$INSTDIRbin'
Call EnvVarUpdate
Pop '$0' )
However, the installation process by itself worked as all the files are
present in the installation directory. I have all the rights on my
machine so it may be not a permission problem. This drives me crazy.
You will find enclosed my CPACK files. If one of you could find what is
wrong with it it would be great.
thanks in advance
Eric
include (InstallRequiredSystemLibraries)
# General CPACK options
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VENDOR Eric Pellegrini - Institut Laue Langevin)
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
# NSIS section
if(CPACK_GENERATOR MATCHES NSIS)
# Create the desktop link
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS CreateShortCut
'$DESKTOPsxtalsoft.lnk' '$INSTDIRbintoolbar.exe' )
# Create the SXTALSOFTSUITE environment variable.
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS WriteRegStr HKCU 'Environment'
'SXTALSOFTSUITE' '$INSTDIR' )
# Update the PATH at installation.
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS Push 'PATH'
Push 'A'
Push 'HKCU'
Push '$INSTDIRbin'
Call EnvVarUpdate
Pop '$0' )
# Update the PATH at uninstallation.
set( CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS Push 'PATH'
Push 'R'
Push 'HKCU'
Push '$INSTDIRbin'
Call un.EnvVarUpdate
Pop '$0' )
# Delete the SXTALSOFTSUITE env variable at uninstallation.
DeleteRegValue HKCU 'Environment' 'SXTALSOFTSUITE'
# Delete the Desktop link at uninstallation.
Delete '$DESKTOPsxtalsoft.lnk' )
# The icon to start the application.
set(CPACK_NSIS_MUI_ICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcsxtalsoft.ico)
# The icon to uninstall the application.
set(CPACK_NSIS_MUI_UNIICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcuninstall_sxtalsoft.ico)
# The icon that appears in top of the installer dialog.
set(CPACK_PACKAGE_ICON
${sxtalsoft_SOURCE_DIR}/toolbar/src/rcsxtalsoft_64.bmp)
# Add a link to the application website in the startup menu.
set(CPACK_NSIS_MENU_LINKS http://forge.ill.eu/projects/sxtalsoft;
Homepage for ${PROJECT_NAME})
# The file that will be displayed in the LICENSE section of the installer.
set(CPACK_RESOURCE_FILE_LICENSE ${sxtalsoft_SOURCE_DIR}LICENSE.txt)
# Set the icon for the application in the Add/Remove programs section.
set(CPACK_NSIS_INSTALLED_ICON_NAME bintoolbar.exe)
# The mail address for the maintainer of the application in the Add/Remove
programs section
set(CPACK_NSIS_CONTACT pellegr...@ill.eu)
# The url of the application in the Add/Remove programs section
set(CPACK_NSIS_URL_INFO_ABOUT http://forge.ill.eu/projects/sxtalsoft)
endif()
set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_EXECUTABLES toolbar ${PROJECT_NAME})
include(CPack)--
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] cache behaviour
Hello CMakers,
I saw this question turning around several times but I do not really
understand why
the explanations do not suit with my problem. Sorry in advance for the
redundancy.
Here is my 'problem':
I have a CMakeLists.txt file that starts with:
##
cmake_minimum_required(VERSION 2.8.0 FATAL_ERROR)
option(GUI Build the GUI on top of the console programs. ON)
if(DEFINED CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING FORCE)
else()
set(CMAKE_BUILD_TYPE Release CACHE STRING FORCE)
endif()
message(STATUS Setting build type to ${CMAKE_BUILD_TYPE})
if(DEFINED CMAKE_Fortran_COMPILER)
set(CMAKE_Fortran_COMPILER ${CMAKE_Fortran_COMPILER} CACHE
STRING FORCE)
else()
set(CMAKE_Fortran_COMPILER ifort CACHE STRING FORCE)
endif()
message(STATUS Setting compiler to ${CMAKE_Fortran_COMPILER})
project(sxtalsoft Fortran RC)
bla bla bla ...
##
When I run it a first time in an empty directory with
cmake -GNMake Makefiles -DCMAKE_Fortran_COMPILER=ifort
-DCMAKE_BUILD_TYPE=Release ..\..\.
I get:
-- Setting build type to Release
-- Setting compiler to ifort
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: C:/Intel/Composer
XE/bin/ia32/ifort.exe
-- Check for working Fortran compiler: C:/Intel/Composer
XE/bin/ia32/ifort.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether C:/Intel/Composer XE/bin/ia32/ifort.exe supports
Fortran 90
-- Checking whether C:/Intel/Composer XE/bin/ia32/ifort.exe supports
Fortran 90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/Users/pellegrini/work/diffraction/sxtalsoft/build/ifort
If a run it a second time WITHOUT deleting the CMakeCache.txt file with
cmake -GNMake Makefiles -DCMAKE_Fortran_COMPILER=ifort
-DCMAKE_BUILD_TYPE=Debug ..\..\.
I get this time:
-- Setting build type to Debug
-- Setting compiler to ifort
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_Fortran_COMPILER= ifort
-- Setting build type to Release
-- Setting compiler to ifort
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: C:/Intel/Composer
XE/bin/ia32/ifort.exe
-- Check for working Fortran compiler: C:/Intel/Composer
XE/bin/ia32/ifort.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether C:/Intel/Composer XE/bin/ia32/ifort.exe supports
Fortran 90
-- Checking whether C:/Intel/Composer XE/bin/ia32/ifort.exe supports
Fortran 90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/Users/pellegrini/work/diffraction/sxtalsoft/build/ifort
There are two things that puzzle me here. The first is: why cmake detect
a change in the compiler
type as it did not change its value in the command line between the two
calls ? The second is why
during the rerun the CMAKE_BUILD_TYPE is set back to Release and not to
the value set in the command
line i.e. Debug ?
Is my implementation not correct or is this some cache behaviour that I
still do not get ?
thanks a lot
Eric
--
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] Default value for CMAKE_BUILD_TYPE
On 5/11/2012 5:30 PM, Jean-Christophe Fillion-Robin wrote: Hi Eric, In our different projects, we use an approach similar to this one: # Set a default build type if none was specified if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES) message(STATUS Setting build type to 'Debug' as none was specified.) set(CMAKE_BUILD_TYPE Debug CACHE STRING Choose the type of build. FORCE) # Set the possible values of build type for cmake-gui set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release MinSizeRel RelWithDebInfo) endif() See http://vtk.org/gitweb?p=VTK.git;a=blob;f=CMakeLists.txt;h=a57fd66ef333fc26bf74fe658c88c3c634f54c3a;hb=HEAD#l12 Hth Jc On Fri, May 11, 2012 at 11:21 AM, pellegrini pellegr...@ill.fr mailto:pellegr...@ill.fr wrote: Hi all, when cmake is run without specifying the build type using -D CMAKE_BUILD_TYPE, it is the Debug mode that is selected as the default. I would like to find a way to use Release as the default value when the user does not specify any build type in the cmake command line. From one of my previous post concerning CMAKE_INSTALL_PREFIX variable, I was thinking to use a similar approach i.e.: project(Foo) if (CMAKE_BUILD_TYPE_INITIALIZED_TO_DEFAULT) set(CMAKE_BUILD_TYPE Release) endif but cmake still sets CMAKE_BUILD_TYPE to Debug in the CMakeCache.txt file. Would you have any idea about what is wrong with my implementation ? thanks a lot. Eric -- Powered by www.kitware.com http://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 -- +1 919 869 8849 Hi Jean-Christophe, I found a hack for my problem. First it seems to be a windows specific problem (I found one other message that mention this). What I did is just to put the following before (compulsory) the project declaration: if (NOT DEFINED CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE CACHE Release STRING hfsfhskj FORCE) endif() It would be interesting to get the feedback of the CMake team about the uglyness of such a hack. Bye Eric -- 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] Default value for CMAKE_BUILD_TYPE
Hi all, when cmake is run without specifying the build type using -D CMAKE_BUILD_TYPE, it is the Debug mode that is selected as the default. I would like to find a way to use Release as the default value when the user does not specify any build type in the cmake command line. From one of my previous post concerning CMAKE_INSTALL_PREFIX variable, I was thinking to use a similar approach i.e.: project(Foo) if (CMAKE_BUILD_TYPE_INITIALIZED_TO_DEFAULT) set(CMAKE_BUILD_TYPE Release) endif but cmake still sets CMAKE_BUILD_TYPE to Debug in the CMakeCache.txt file. Would you have any idea about what is wrong with my implementation ? thanks a lot. Eric -- 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] avoiding complete rebuild when the user changes
Dear CMakers, I introduced recently a colleague of mine to the wonders of cmake. He has a problem that neither he or me could solve. When he cmakes and builds his project as root and builds subsenquently its project as himself the whole project is rebuilt even if nothing has been changed. I may be wrong but I think this is not an actual problem with cmake but rather a general property of make that do not consider only the timestamp but also the owner of a file and if one of these changes, the file is marked as having to be rebuild. What do you think ? Would you see one way to escape from this feature ? thanks a lot see you Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] About CMAKE_INSTALL_PREFIX
Hello everbody,
I would like to understand a bit more one feature related to
CMAKE_INSTALL_PREFIX initialization.
When reading the documentation, it is specified that this variable
contains the directory that will be pre-pended to all install
directories and that it should be defaulted to C:/Program Files on
Windows. However, in my current build the variable is not defaulted to
C:/Program Files but to C:/Program Files/libcrysfml where crysfml is
the name of my base project.
This unexpected feature (at least to my understanding !) leads me to my
second question.
I would like to get rid of the crysfml subdirectory in the value of
CMAKE_INSTALL_PREFIX. I could obvioulsy
use:
get_filename_component(MY_CMAKE_INSTALL_PREFIX
${CMAKE_INSTALL_PREFIX} PATH)
but this would fail if CMAKE_INSTALL_PREFIX is set on the cmake command
line by the user because, in such case, the installation will not be
done in the directory that he provided but in its parent directory.
Rather counter-intuitive.
What I would need is a mechanism to detect whether the
CMAKE_INSTALL_PREFIX has been set or not by the user on the
command-line. If so, I take directly the values he provided, and if not
so, I take the parent directory of the default value.
Is that possible ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] About CMAKE_INSTALL_PREFIX - solved
Great, thanks a lot Rolf Michael
Rolf Eike Beer a écrit :
Hello everbody,
I would like to understand a bit more one feature related to
CMAKE_INSTALL_PREFIX initialization.
When reading the documentation, it is specified that this variable
contains the directory that will be pre-pended to all install
directories and that it should be defaulted to C:/Program Files on
Windows. However, in my current build the variable is not defaulted to
C:/Program Files but to C:/Program Files/libcrysfml where crysfml is
the name of my base project.
This unexpected feature (at least to my understanding !) leads me to my
second question.
I would like to get rid of the crysfml subdirectory in the value of
CMAKE_INSTALL_PREFIX. I could obvioulsy
use:
get_filename_component(MY_CMAKE_INSTALL_PREFIX
${CMAKE_INSTALL_PREFIX} PATH)
but this would fail if CMAKE_INSTALL_PREFIX is set on the cmake command
line by the user because, in such case, the installation will not be
done in the directory that he provided but in its parent directory.
Rather counter-intuitive.
What I would need is a mechanism to detect whether the
CMAKE_INSTALL_PREFIX has been set or not by the user on the
command-line. If so, I take directly the values he provided, and if not
so, I take the parent directory of the default value.
Is that possible ?
if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
...
endif ()
Eike
--
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] Actual effect of set_source_files_properties with COMPILE_FLAGS - solved
Hello everybody,
that's finally OK. Indeed; everything was OK. I did not pay attention
that the flag was actually here. I was simply not looking
in the right place. Perhaps new glasses or some rest should be my first
resolution for 2012 !!!
sorry for the inconvenience
Eric
pellegrini a écrit :
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
--
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] RC compiler on Linux - new problem
Hi Michael
first of all best wishes for 2012 !
Let's start 2012 with a new question for CMake community ! It is related
with prior discussions we had about rc
compiler on Linux. Sorry but I had many things to do in the meantime and
I could only come back to it recently.
As a reminder, my problem was:
- I must use the winteracter Fortran library resource compiler
- it does not accept any output flag so that the output resource
object is always created in-source
- on Linux, it produces a .o object file instead of a .res file
which mess up the rc process of CMake
I tried your last suggestion that was to create a wrapper script and use
it as the RC when I set the WINTERACTER_RC_COMPILER variable. My
CMakeLists.txt file looks now like:
...
IF(${WINTERACTER_RC_COMPILER})
CONFIGURE_FILE(winteracter_rc.sh.in winteracter_rc.sh @ONLY)
SET(CMAKE_RC_COMPILER winteracter_rc.sh CACHE STRING RC compiler FORCE)
ENDIF()
PROJECT(toto Fortran RC)
...
that I build with cmake -GUnix Makefile -DWINTERACTER_RC_COMPILER=ON ..\.
However, the build ends up with an infinite loop that replicates endlessly the
following pattern:
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort
-- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90
-- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90 -- yes
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_RC_COMPILER= winteracter_rc.sh
would you have an idea of what is going wrong with my settings ?
thanks a lot
Eric
Michael Hertling a écrit :
On 10/25/2011 10:16 AM, pellegrini wrote:
Hi Michael,
I tried to adapt the files you gave me to my project. It almost works.
As a reminder, there were a CMakeLists.txt with an overloaded
add_executable function that created a sym_link for the rc files and a
shell file (rc.sh) used to suit the rc compiler call to my needs.
I found one problem that I still not have solved. The shell script is
declared under the following command:
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash rc.sh
CMAKE_RC_COMPILER SOURCE OBJECT)
However, this command makes that even my f90 files uses the rc compiler
which obvioulsy makes my build crash. I tried to use something like
set_property(SOURCE myrcfile.rc PROPERTY RULE_LAUNCH_COMPILE ... in
order to apply the patch only when a rc file is under process but
unfortunately this property is not a valid source properties.
Would you see any way to circumvent that problem ?
thanks
Eric
The rc.sh script is designed to differentiate between an RC invocation
and something else; this is why it is called with the RC as the first
argument. If the first argument of the actual command line is equal
to CMAKE_RC_COMPILER, the command line is modified to adapt to the
winteracter RC; otherwise, it is executed without modification. Watch
out for the lines starting with Executing ... in the output of Make.
If it still does not work, could you provide a small self-contained
example which demonstrates the issue for further investigation?
However, I reconsidered your concern in the meantime. Possibly, it's a
more appropriate approach to use a wrapper script for the winteracter
RC to adapt the latter to CMake's expectations. This script should:
- accept parameters according to Modules/CMakeRCInformation.cmake,
- link or copy the source file to a temporary directory the
winteracter RC can write its output file to thereafter,
- move the output file where it's expected by CMake.
This wrapper can be enabled when WINTERACTER_RC_COMPILER is set at
the initial configuration of the project, so you don't need to re-
implement ADD_EXECUTABLE() et al. - which works only once anyway -
or to rely on the Makefile-specific RULE_LAUNCH_COMPILE property,
and the RC files still don't need to be handled specially, which
has been the idea of ADD_EXECUTABLE()'s reimplementation. However,
the downside is that you can not use CMake anymore to detect the
winteracter RC automatically; you must do it by yourself before
the PROJECT() or ENABLE_LANGUGAE() command, e.g.
IF(WINTERACTER_RC_COMPILER)
CONFIGURE_FILE(rc.sh.in rc.sh @ONLY)
SET(CMAKE_RC_COMPILER ${CMAKE_BINARY_DIR}/rc.sh
CACHE STRING RC compiler FORCE)
ENDIF()
PROJECT(... RC)
with a template rc.sh.in for the wrapper script rc.sh, containing
@WINTERACTER_RC_COMPILER@ somewhere. In this way, anything should
work as usual if WINTERACTER_RC_COMPILER is not set at the initial
configuration of the project, but if it is set, the wrapper script
is configured and forced to be used as the RC, and the subsequent
PROJECT() or ENABLE_LANGUGAE
[CMake] Determine 32 vs 64 bit cpu
Hi all, I have a program that uses an external library whose path name depends on its version (32 or 64 bit). Is there a direct way in cmake to test whether my cpu is 32 or 64 bit ? The one I found up to now is the following: if(CMAKE_SIZEOF_VOID_P EQUAL 8) set(arch_64 TRUE) else() set(arch_64 FALSE) endif() thanks a lot and merry Christmas ! Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] RC compiler on Linux - new problem
Hi Michael,
I tried to adapt the files you gave me to my project. It almost works.
As a reminder, there were a CMakeLists.txt with an overloaded
add_executable function that created a sym_link for the rc files and a
shell file (rc.sh) used to suit the rc compiler call to my needs.
I found one problem that I still not have solved. The shell script is
declared under the following command:
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash rc.sh
CMAKE_RC_COMPILER SOURCE OBJECT)
However, this command makes that even my f90 files uses the rc compiler
which obvioulsy makes my build crash. I tried to use something like
set_property(SOURCE myrcfile.rc PROPERTY RULE_LAUNCH_COMPILE ... in
order to apply the patch only when a rc file is under process but
unfortunately this property is not a valid source properties.
Would you see any way to circumvent that problem ?
thanks
Eric
pellegrini a écrit :
thanks a lot Michael.
Finally, this was not such a trivial problem but I should find my way
with the examples you gave me.
Eric
Michael Hertling a écrit :
On 10/21/2011 06:49 PM, pellegrini wrote:
Hi all,
after digging and googling some hours I did a first step in the
right direction.
I had to add the command:
enable_language(rc)
set(cmake_rc_compiler_arg1 -cif8)
The resource compiler I (must) use is the one provided by
winteracter Fortran library.
This led me to a serie of problems related to the use of this compiler:
- it does not accept any output flag so that the output resource
object is always created in-source in the rc file directory.
- on Linux, it produces a .o object file instead of a .res file
Looking at the CMakeRCInformation.cmake I see that by construction
CMake will use the following compile command:
CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE
with a resource object file with a .res extension.
You might rewrite this rule variable, e.g. in order to drop
/foOBJECT, but this wouldn't resolve your issues, AFAICS.
On a Linux machine, this produces a wrong build command line with
the path for the output object file being /foCMakeFiles/ This
problem was raised sometime ago in the mantis bug tracker but
unfortunatley the patch proposed apply for mingw using windres but
not for Linux.
Is there a fix for this ?
If no, is there a way to inform the linker that:
- my resource object file is located in-source
You might create symlinks to the resource files - or copy them - so
that the winteracter RC generates its output files within the build
tree; note that the source tree may be read-only. This could even be
done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY().
- the extension is not .res but .o
You might use a RULE_LAUNCH_COMPILE property in conjunction with a
shell script which recognizes RC command lines, moves the .o to a
.res in the correct directory and drops the undesired /fo switch.
The attached CMakeLists.txt and rc.sh files outline these approaches;
check them out with meaningful ${CMAKE_SOURCE_DIR}/{abs,srcdir}.rc
and ${CMAKE_BINARY_DIR}/bindir.rc. However, they are untested as I
currently haven't any RC at hand; moreover, they're restricted to
Makefiles and won't work on Windows.
Regards,
Michael
pellegrini a écrit :
Hi all,
I use CMake 2.8.5 on Linux and Windows machine to build a Fortran
project.
On Windows, no problem, the build and the resulting GUI are OK. On
Linux, the build seems to
be OK but the resulting GUI gives an empty screen. Discussing with
Michael a few days ago made
me think that it could be related to the use of an inappropriated
motif library.
However, looking in more details I see with a make VERBOSE=1 that
my rc file is not built
(I do not see the line Building RC object ...). even if it is
declared as one of my sources files.
Is there some extra commands to specify to make cmake recognize and
compile a rc file ?
thanks
Eric
--
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] RC compiler on Linux - new problem - solved
thanks a lot Michael.
Finally, this was not such a trivial problem but I should find my way
with the examples you gave me.
Eric
Michael Hertling a écrit :
On 10/21/2011 06:49 PM, pellegrini wrote:
Hi all,
after digging and googling some hours I did a first step in the right
direction.
I had to add the command:
enable_language(rc)
set(cmake_rc_compiler_arg1 -cif8)
The resource compiler I (must) use is the one provided by winteracter
Fortran library.
This led me to a serie of problems related to the use of this compiler:
- it does not accept any output flag so that the output resource
object is always created in-source in the rc file directory.
- on Linux, it produces a .o object file instead of a .res file
Looking at the CMakeRCInformation.cmake I see that by construction CMake
will use the following compile command:
CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE
with a resource object file with a .res extension.
You might rewrite this rule variable, e.g. in order to drop
/foOBJECT, but this wouldn't resolve your issues, AFAICS.
On a Linux machine, this produces a wrong build command line with the
path for the output object file being /foCMakeFiles/ This problem
was raised sometime ago in the mantis bug tracker but unfortunatley the
patch proposed apply for mingw using windres but not for Linux.
Is there a fix for this ?
If no, is there a way to inform the linker that:
- my resource object file is located in-source
You might create symlinks to the resource files - or copy them - so
that the winteracter RC generates its output files within the build
tree; note that the source tree may be read-only. This could even be
done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY().
- the extension is not .res but .o
You might use a RULE_LAUNCH_COMPILE property in conjunction with a
shell script which recognizes RC command lines, moves the .o to a
.res in the correct directory and drops the undesired /fo switch.
The attached CMakeLists.txt and rc.sh files outline these approaches;
check them out with meaningful ${CMAKE_SOURCE_DIR}/{abs,srcdir}.rc
and ${CMAKE_BINARY_DIR}/bindir.rc. However, they are untested as I
currently haven't any RC at hand; moreover, they're restricted to
Makefiles and won't work on Windows.
Regards,
Michael
pellegrini a écrit :
Hi all,
I use CMake 2.8.5 on Linux and Windows machine to build a Fortran
project.
On Windows, no problem, the build and the resulting GUI are OK. On
Linux, the build seems to
be OK but the resulting GUI gives an empty screen. Discussing with
Michael a few days ago made
me think that it could be related to the use of an inappropriated
motif library.
However, looking in more details I see with a make VERBOSE=1 that my
rc file is not built
(I do not see the line Building RC object ...). even if it is
declared as one of my sources files.
Is there some extra commands to specify to make cmake recognize and
compile a rc file ?
thanks
Eric
--
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] RC compiler on Linux
Hi all, I use CMake 2.8.5 on Linux and Windows machine to build a Fortran project. On Windows, no problem, the build and the resulting GUI are OK. On Linux, the build seems to be OK but the resulting GUI gives an empty screen. Discussing with Michael a few days ago made me think that it could be related to the use of an inappropriated motif library. However, looking in more details I see with a make VERBOSE=1 that my rc file is not built (I do not see the line Building RC object ...). even if it is declared as one of my sources files. Is there some extra commands to specify to make cmake recognize and compile a rc file ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] RC compiler on Linux - new problem
Hi all, after digging and googling some hours I did a first step in the right direction. I had to add the command: enable_language(rc) set(cmake_rc_compiler_arg1 -cif8) The resource compiler I (must) use is the one provided by winteracter Fortran library. This led me to a serie of problems related to the use of this compiler: - it does not accept any output flag so that the output resource object is always created in-source in the rc file directory. - on Linux, it produces a .o object file instead of a .res file Looking at the CMakeRCInformation.cmake I see that by construction CMake will use the following compile command: CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE with a resource object file with a .res extension. On a Linux machine, this produces a wrong build command line with the path for the output object file being /foCMakeFiles/ This problem was raised sometime ago in the mantis bug tracker but unfortunatley the patch proposed apply for mingw using windres but not for Linux. Is there a fix for this ? If no, is there a way to inform the linker that: - my resource object file is located in-source - the extension is not .res but .o thanks for your help Eric pellegrini a écrit : Hi all, I use CMake 2.8.5 on Linux and Windows machine to build a Fortran project. On Windows, no problem, the build and the resulting GUI are OK. On Linux, the build seems to be OK but the resulting GUI gives an empty screen. Discussing with Michael a few days ago made me think that it could be related to the use of an inappropriated motif library. However, looking in more details I see with a make VERBOSE=1 that my rc file is not built (I do not see the line Building RC object ...). even if it is declared as one of my sources files. Is there some extra commands to specify to make cmake recognize and compile a rc file ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] Mixing static and dynamic library
Hi all, I would like to port a hardcoded build line from an old make file to my CMakeLists.txt file for a fortran 90 project using ifort compiler. The line is the following: ifort *.o -o myexec -static-intel -Bstatic -lXm -Bdynamic -lXt First, if I get it right (sorry for my ignorance but I come from the python world where I was quite preserved from these lines !!!), the goal is to build an executable: - statically bound to the intel libraries - statically bound to libXm library - dynamically bound to libXt library A locate told me that on my machine both Xt and Xm are in dynamic form (libXm.so.2, libXt.so.6) and in a standard location (/usr/lib). So in my CMakeLists.txt file, I tried: set(CMAKE_Fortran_FLAGS_RELEASE -static-intel) add_executable(myexec $SOURCES) target_link_libraries(myexec -Bdynamic Xm Xt) when building the project I get an error at link time (ld: cannot find -lXm). Would you have any idea of what is going wrong with my settings ? thanks a lot Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] Linker flags not considered
Hi all, I would like to build a project using intel fortran compiler. When building the project I would like to add/change two linker flags: - /stack:12800 - /subsystem:windows (when launched, the executable (GUI) will not launch any additional terminal) To do so, I simply added in my CMakeLists.txt file the following line: set(CMAKE_EXE_LINKER_FLAGS /stack:12800 /subsystem:windows) Unfortunately, when starting my application, there is still a terminal window that pops up. So the /subsystem:windows seems to have been skipped by the linker (and I guess also the /stack:12800 flag). I also try (by the way what is the difference ?): set(LINK_FLAGS /stack:12800 /subsystem:windows) but it also produced the same unwanted effect. did I miss something somewhere ? thanks for your help Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- \n 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] Linker flags not considered - solved
that's work ! Great ! Thanks a lot Rolf Rolf Eike Beer a écrit : On Mi., 12. Okt. 2011 17:05:52 CEST, pellegrini pellegr...@ill.fr wrote: Hi all, I would like to build a project using intel fortran compiler. When building the project I would like to add/change two linker flags: - /stack:12800 - /subsystem:windows (when launched, the executable (GUI) will not launch any additional terminal) This usually means you want to add the WIN32 flag in your ADD_EXECUTABLE call. See the documentation of it. Eike -- 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 -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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_RESOURCE_FILE_WELCOME has no effect with NSIS
Hi all,
I would like to package my application using CPACK/NSIS generator.
Using the following line:
set(CPACK_RESOURCE_FILE_WELCOME ${CMAKE_CURRENT_SOURCE_DIR}/README.txt)
has no effect. Indeed, my installer still show at start up the default
wellcome message.
Looking on the web, I found that this bug was raised some time ago
(http://www.kwwidgets.org/Bug/view.php?id=7880nbn=2). Has it been
solved since then ?
In the meantime, as a workaround, I was thinking about adding
explicitely the NSIS commands using CPACK_NSIS_EXTRA_INSTALL_COMMANDS.
What do you think about ?
thanks for your help
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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_RESOURCE_FILE_WELCOME has no effect with NSIS - solved
This option is valid only for PackageMaker generator. I was not careful
enough when looking at the doc :-[
sorry
Eric
pellegrini a écrit :
Hi all,
I would like to package my application using CPACK/NSIS generator.
Using the following line:
set(CPACK_RESOURCE_FILE_WELCOME
${CMAKE_CURRENT_SOURCE_DIR}/README.txt)
has no effect. Indeed, my installer still show at start up the
default wellcome message.
Looking on the web, I found that this bug was raised some time ago
(http://www.kwwidgets.org/Bug/view.php?id=7880nbn=2). Has it been
solved since then ?
In the meantime, as a workaround, I was thinking about adding
explicitely the NSIS commands using CPACK_NSIS_EXTRA_INSTALL_COMMANDS.
What do you think about ?
thanks for your help
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] modifying the PATH during NSIS intallation
Hi all, I recently discovered the (very) useful CPack program from CMake. I would like to build an NSIS installer that, when launched, will, as well as installing my package, will also modify the PATH with the directory where my executables have been installed. Is that something (if so, how) that fall in the scope of CPACK_INSTALL_COMMANDS ? thanks a lot Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] Sharing objects between executables - solved
thanks for your help Alexander Michael.
Eric
Michael Hertling a écrit :
On 10/04/2011 10:42 AM, pellegrini wrote:
Hi all,
I would need your advise about the strategy to adopt when two
executables share common object files.
Sharing object files among different targets might mean asking for
trouble - possibly quite subtle trouble - since different targets'
object files may need to be compiled with different sets of flags,
defines etc.; in particular, think of -fPIC w.r.t. object files
destined for a static library as well as for a shared one.
Here is the context. I have a project that consists in a program (e.g.
console_prog) that was historically a console program
on top of which a GUI (gui_prog) was built. The gui_prog calling
directly the console program via an input file generated by the GUI.
As the gui by itself does not mean anything without its console partner,
I built a CMakeLists.tx file that contains two add_executables:
- add_executable(console_prog console_prog.f90 module1.f90
module2.f90 module3.f90 ...)
- add_executable(gui_prog gui_prog.f90 module1.f90 module2.f90)
My problem is that gui_prog uses some routines included in the source
files of the console program (e.g. module1.f90 module2.f90).
I would like to avoid a double build of module1.f90, module2.f90
I see two possibilities:
- building a static libraries out of the common files and linking it
to both console_prog and gui_prog executables
Unless you have very good reasons to not do so, this is definitely what
you should aim at. Besides, that's the basic idea of object libraries.
- using the set_source_files_properties command on the objects files
generated by pfind build with GENERATED option set to true.
Which approach do you think suit the best to my purpose ? If this is the
second one: is there an easy way to get/specify the list of the
object files generated during the pfind build ?
You might use a RULE_LAUNCH_COMPILE target property for this purpose:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LOF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main1 main.c)
SET_TARGET_PROPERTIES(main1 PROPERTIES RULE_LAUNCH_COMPILE sh
${CMAKE_SOURCE_DIR}/lof.sh OBJECT ${CMAKE_BINARY_DIR}/\$\$(basename
SOURCE).o)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/main.c.o PROPERTIES
GENERATED TRUE)
ADD_EXECUTABLE(main2 ${CMAKE_BINARY_DIR}/main.c.o)
SET_TARGET_PROPERTIES(main2 PROPERTIES LINKER_LANGUAGE C)
# lof.sh:
ln -s $1 $2; shift 2; exec $@
However, this approach is limited to Makefile generators and makes use
of platform-specific tools like basename, so it's usually inadvisable.
Regards,
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] Sharing objects between executables
Hi all, I would need your advise about the strategy to adopt when two executables share common object files. Here is the context. I have a project that consists in a program (e.g. console_prog) that was historically a console program on top of which a GUI (gui_prog) was built. The gui_prog calling directly the console program via an input file generated by the GUI. As the gui by itself does not mean anything without its console partner, I built a CMakeLists.tx file that contains two add_executables: - add_executable(console_prog console_prog.f90 module1.f90 module2.f90 module3.f90 ...) - add_executable(gui_prog gui_prog.f90 module1.f90 module2.f90) My problem is that gui_prog uses some routines included in the source files of the console program (e.g. module1.f90 module2.f90). I would like to avoid a double build of module1.f90, module2.f90 I see two possibilities: - building a static libraries out of the common files and linking it to both console_prog and gui_prog executables - using the set_source_files_properties command on the objects files generated by pfind build with GENERATED option set to true. Which approach do you think suit the best to my purpose ? If this is the second one: is there an easy way to get/specify the list of the object files generated during the pfind build ? thanks a lot Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] Sharing objects between executables
Hi all, I would need your advise about the strategy to adopt when two executables share common object files. Here is the context. I have a project that consists in a program (e.g. console_prog) that was historically a console program on top of which a GUI (gui_prog) was built. The gui_prog calling directly the console program via an input file generated by the GUI. As the gui by itself does not mean anything without its console partner, I built a CMakeLists.tx file that contains two add_executables: - add_executable(console_prog console_prog.f90 module1.f90 module2.f90 module3.f90 ...) - add_executable(gui_prog gui_prog.f90 module1.f90 module2.f90) My problem is that gui_prog uses some routines included in the source files of the console program (e.g. module1.f90 module2.f90). I would like to avoid a double build of module1.f90, module2.f90 I see two possibilities: - building a static libraries out of the common files and linking it to both console_prog and gui_prog executables - using the set_source_files_properties command on the objects files generated by console_prog build with GENERATED option set to true. Which approach do you think suit the best to my purpose ? If this is the second one: is there an easy way to get/specify the list of the object files generated during the console_prog build ? thanks a lot Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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 -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] multiple source directories
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do so, in
the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring the
sources for a project. I tried using the option CMAKE_USE_RELATIVE_PATHS
but it might not be defined for that purpose as it did not solve the
problem. Would you have any idea how to solve that problem ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] multiple source directories - solved
thanks for the hints and your help, guys. Indeed, There was one '..\'
too much in my source files path.
Eric
Andreas Pakulat a écrit :
On 28.09.11 12:51:53, pellegrini wrote:
Hi all,
I have a project with the following structure:
root/
CMakeLists.txt
prog1/
CMakeLists.txt
Src/
file1.f90
prog2/
CMakeLists.txt
Src/
file2.f90
where prog1, prog2 are individual projects.
I would like to add file1.90 to the build process of prog2. To do
so, in the CMakeLists.txt file of prog2 project, I put:
set(SOURCES ../../prog1/Src/file1.f90
Src/file2.f90)
and further
add_executable(prog2 ${SOURCES})
when compiling with CMake I get the following error:
##
CMake Error at CMakeLists.txt:35 (add_executable):
Cannot find source file:
../../prog1/Src/file1.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
###
It seems that CMake cna not deal with relative path when declaring
the sources for a project.
Relative paths work just fine, but your expecting a different base-path
than cmake is. In the above example the current directory when
assembling the sources is root/prog2 not root/prog2/Src which you seem
to assume. Hence you have one .. too much in your set-line. This
should work:
set( SOURCES ../prog1/Src/file1.f90 Src/file2.f90 )
Andreas
--
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] The output of cpack is an empty file
Hello everybody,
I would like to use cpack in order to gather a set of executables (built
statically) into a single archive that could be extracted everywhere the
user wants.
My project architecture is the following:
collections\
CMakeLists.txt
prog1\
CMakeLists.txt + source files
prog2\
CMakeLists.txt + source files
prog3\
CMakeLists.txt + source files
where each CMakeLists.txt files are stand-alone CMake projects
(historically each program still has to be buildable alone) that
produces prog1, prog2, prog3 executables.
My main CMakeLists.txt looks like:
##
project(collections)
add_subdirectory(prog1)
add_subdirectory(prog2)
add_subdirectory(prog3)
set(CPACK_GENERATOR ZIP)
set(CPACK_PACKAGE_DESCRIPTION_FILE ${CMAKE_CURRENT_SOURCE_DIR}/README)
set(CPACK_PACKAGE_NAME collection of progs)
set(CPACK_PACKAGE_FILE_NAME collections)
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
set(CPACK_PACKAGE_EXECUTABLES collections)
include(CPack)
##
when running cmake and then nmake package, the built is done, cpack is
launched but the resulting archive is empty. No README inside and more
disturbing no
prog1, prog2, prog3 executables. I may have miss something when reading
the examples but I still have not found what. Would you have any idea ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
--
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] The output of cpack is an empty file - solved
Eric Noulard a écrit : 2011/9/27 pellegrini pellegr...@ill.fr: Hi Eric, thanks for your quick answer. No, my subprojects do not contains any CPack directives neither include cpack. Should they ? Sorry my fingers slipped. Another message is coming to the list. You need an INSTALL rule for each patr you want to have in your package Eric, I could finally find the command to also include the excutable. This was based on the hint you gave me a few minutes ago. I placed in the CMakeLists.txt file of my prog1 subprojects: install(TARGETS prog1 RUNTIME DESTINATION .) so everything is OK now. I just hope that this install command will not break cmake when prog1 is built as a stand-alone. I will check. thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France -- 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] LINKER FLAGS
Hi all, I would like to build a Fortran90 project using Fortran intel compiler. I would like to increase the stack by adding the /stack flag to the linker. Looking on the documentation, I think that set(CMAKE_EXE_LINKERS_FLAG /stack:6400) will do the job but I was wondering if using this command will remove the list of flags that may be set by cmake (behaviour that I would like to avoid) or just append it to this list ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] LINKER FLAGS
thanks for the hint Eric Michael
Eric
Michael Wild a écrit :
On 09/13/2011 10:35 AM, pellegrini wrote:
Hi all,
I would like to build a Fortran90 project using Fortran intel compiler.
I would like to increase the stack by adding the /stack
flag to the linker.
Looking on the documentation, I think that set(CMAKE_EXE_LINKERS_FLAG
/stack:6400) will do the job but I was wondering if using this
command will remove the list of flags that may be set by cmake
(behaviour that I would like to avoid) or just append it to this list ?
thanks
Eric
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} /stack:6400)
Also, if you want to apply this to only a single target, you should
probably use the LINK_FLAGS target property instead. There you don't
have to worry about appending.
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] 64 bit flags
Hello everybody, I have a Fortran project that is currently built (using gfortran, g95 or ifort) on 32 bits machines but that might need quite soon to be built on 64 bit machines as well. Does cmake automatically detect the processor architecture and add the 64 bit flag at configuration time or do I have to declare those flags through, for example, a '-D option ? thanks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Fwd: 64 bit flags
Thanks a lot Eric for the clear explanation. Eric Eric Noulard a écrit : I did forget the ML. -- Forwarded message -- From: Eric Noulard eric.noul...@gmail.com Date: 2011/9/9 Subject: Re: [CMake] 64 bit flags To: pellegrini pellegr...@ill.fr 2011/9/9 pellegrini pellegr...@ill.fr: Hello everybody, I have a Fortran project that is currently built (using gfortran, g95 or ifort) on 32 bits machines but that might need quite soon to be built on 64 bit machines as well. Does cmake automatically detect the processor architecture and add the 64 bit flag at configuration time or do I have to declare those flags through, for example, a '-D option ? CMake chose the default target architecture of your compiler so if the default target ofthe compiler is 64bits no need for special flags. To be more clear: If I compile some code on a 32bits host the compiler (C, Fortran or whatever) usually produce 32bits binaries If I compile some code on a 64 bits host the compiler (C, Fortran or whatever) usually produce 64bits binaries So CMake detect the compiler (C; Fortran, ...) and do not care about 32/64 bits issue. Now if YOUR code as 32/64 bits specific zone then you need an appropriate macro whose definition may be done by you (in CMakeLists.txt) by testing the value of CMAKE_SIZEOF_VOID_P. Now some platform like Mac OS support multi-arch binaries and if you crawl the mail archive you'll find discussion about that. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY
Hello everybody,
I use CMake 2.8.4, Fortran 90 and Intel compiler to build an executable.
I read in the documentation that
RUNTIME_OUTPUT_DIRECTORY supercedes the old EXECUTABLE_OUTPUT_PATH command.
When using:
add_executable(myexec ${source_files})
set(EXECUTABLE_OUTPUT_PATH mydir)
I can find my executable in mydir but when using
add_executable(myexec ${source_files})
set(RUNTIME_OUTPUT_DIRECTORY mydir)
nothing appears in mydir. Did I miss something when reading the doc ?
I would have an additional question concerning both commands. Anytime I
build my project the following files are created alongside my executable:
- myexec.exe.embed.manifest
- myexec.exe.embed.manifest.res
- myexec.exe.intermediate.manifest
- myexec.exe.resource.txt
- myexec.ilk
is there a way to get rid of these files ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY
Michael Wild a écrit :
On 07/22/2011 03:46 PM, pellegrini wrote:
Hello everybody,
I use CMake 2.8.4, Fortran 90 and Intel compiler to build an executable.
I read in the documentation that
RUNTIME_OUTPUT_DIRECTORY supercedes the old EXECUTABLE_OUTPUT_PATH command.
When using:
add_executable(myexec ${source_files})
set(EXECUTABLE_OUTPUT_PATH mydir)
I can find my executable in mydir but when using
add_executable(myexec ${source_files})
set(RUNTIME_OUTPUT_DIRECTORY mydir)
nothing appears in mydir. Did I miss something when reading the doc ?
I would have an additional question concerning both commands. Anytime I
build my project the following files are created alongside my executable:
- myexec.exe.embed.manifest
- myexec.exe.embed.manifest.res
- myexec.exe.intermediate.manifest
- myexec.exe.resource.txt
- myexec.ilk
is there a way to get rid of these files ?
thanks a lot
Eric
RUNTIME_OUTPUT_DIRECTORY is a *property*, not a variable. If you want to
set a variable, use CMAKE_RUNTIME_OUTPUT_DIRECTORY.
HTH
Oups ! sorry.
Thanks for the hints Michael. That's OK, my executable is now created in
the selected directory. Unfortunately, it does not come alone, there are
still those manifest and ilk files ...
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
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] Problem running cmake 2.8.4 on Ubuntu 10.04
Hello everybody, I have troubles running cmake 2.8.4 on my ubuntu 10.04 machine. I must use that version because of a bug fix concerning rc files. When running cmake, I get the following error message: ## -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: /home/pellegrini/bin/ifort -- Check for working Fortran compiler: /home/pellegrini/bin/ifort -- works -- Detecting Fortran compiler ABI info CMake Error at /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31 (TRY_COMPILE): Cannot copy output executable '' to destination specified by COPY_FILE: '/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find the executable at any of: /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/cmTryCompileExec /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Development/cmTryCompileExec Call Stack (most recent call first): /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:73 (PROJECT) -- Detecting Fortran compiler ABI info - done CMake Error at /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:48 (FILE): file STRINGS file /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin cannot be read. Call Stack (most recent call first): /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:73 (PROJECT) -- Checking whether /home/pellegrini/bin/ifort supports Fortran 90 -- Checking whether /home/pellegrini/bin/ifort supports Fortran 90 -- yes -- Configuring incomplete, errors occurred! ## The same settings work well on my windows machine ... would you have any idea ? thans in advance Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Problem running cmake 2.8.4 on Ubuntu 10.04
thanks Alan for your help, indeed 'ifort_release_win' stands for a build with ifort using a graphical user interface. I just realize it was certainly not the best name for my build directory (ifort_release_gui would have led to less confusion I guess). In the meantime, I found that cmake 2.8.0, 2.8.1, 2.82 works and starting from 2.8.3 the ABI steps fails. I may be wrong but it seems to be related to some addings in the version 2.8.3 and 2.8.4. Eric Alan W. Irwin a écrit : On 2011-07-06 11:36+0200 pellegrini wrote: Hello everybody, I have troubles running cmake 2.8.4 on my ubuntu 10.04 machine. I must use that version because of a bug fix concerning rc files. When running cmake, I get the following error message: ## -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: /home/pellegrini/bin/ifort -- Check for working Fortran compiler: /home/pellegrini/bin/ifort -- works -- Detecting Fortran compiler ABI info CMake Error at /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31 (TRY_COMPILE): Cannot copy output executable '' to destination specified by COPY_FILE: '/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find the executable at any of: /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/cmTryCompileExec /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Development/cmTryCompileExec Call Stack (most recent call first): /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:73 (PROJECT) -- Detecting Fortran compiler ABI info - done CMake Error at /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:48 (FILE): file STRINGS file /home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin cannot be read. Call Stack (most recent call first): /home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:73 (PROJECT) -- Checking whether /home/pellegrini/bin/ifort supports Fortran 90 -- Checking whether /home/pellegrini/bin/ifort supports Fortran 90 -- yes -- Configuring incomplete, errors occurred! ## The same settings work well on my windows machine ... would you have any idea ? Hi Eric: I have no experience with ifort, but I do have just a quick thought which may or may not have anything to do with the Linux build errors you are seeing. I noticed ifort_release_win in your above error messages. Just in case that win has anything to do with your Windows build, you must do your Linux build starting with a completely empty build tree. For example, stale Windows build results in that tree would completely mess up your Linux build. Even if you confine your builds to one platform, if things go wrong (like above) it is always a good idea to start over with a fresh build starting with an empty build tree in case your build is getting messed up by stale build results on the same platform. Of course, none of these comments are relevant if you get the above error messages starting with an empty build tree. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Post-build copy
Hello everybody,
I build a static fortran library using CMake 2.8.0. Once the built is
done I would like to copy the library archive and its related Fortran
mod files stored in say, my_dir1, in another directory say, my_dir2.
Looking on the mailing list and on the web, I tried the following but
nothing happens:
ADD_CUSTOM_COMMAND(
TARGET crysfml
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory my_dir2
COMMAND ${CMAKE_COMMAND} -E copy_directory my_dir1 my_dir2)
Am I doing something wrong ? Any idea ?
thanks a lot
See you
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] Strange behaviour with -D option
Hello everybody, there is a behaviour I do not understand when using cmake with -D option. In my project I defined a few CACHE variables. One of them is GUI to specify whether or not my project should be built with graphical library support. So in my main CMakeLists.txt I wrote something like: SET(GUI FALSE CACHE BOOL do the build in GUI mode) PROJECT(crysfml Fortran) ... When launching cmake with: cmake -G NMake Makefiles -D CMAKE_Fortran_COMPILER=ifort -D GUI=TRUE ..\..\. I always get the following message # GUI VALUE = TRUE -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= ifort -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe -- Check for working Fortran compiler: C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe supports Fortran 90 -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe supports Fortran 90 -- yes GUI VALUE = FALSE -- Configuring done -- Generating done -- Build files have been written to: C:/Datas/Eclipse/workspace/crysfml/build/ifort_release_win # and the worse it that when deleting the cache and rebuilding it, the GUI variable is switched to FALSE as you can see in the two MESSAGE commands I put in my code (GUI VALUE =). Though, I would tend to think that the -D command should have the last word. There should be something I completely missed. thanks a lot see you Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Multiple output directories
Hello everybody, I would like to know if there is a cmake command to place my generated executable in several directories in one shot. Using SET(EXECUTABLE_OUTPUT_PATHmy_path1) will allow to customize the place where my executable should be placed but only in a single directory I guess. Any idea ? thanks a lot Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Resource file skipped without warning
Hello everybody,
I am using CMake 2.8 to build a Fortran executable that uses Winteracter
graphical library.
The build is performed using Intel Fortran Compiler.
I read in previous discussion
(http://www.cmake.org/pipermail/cmake/2004-January/004664.html)
that just adding the rc file as a source file should work but apparently
not. When building my project the rc filed seems to be skipped.
I used the following set of commands:
###
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(sxtalsoftsuite Fortran)
set(source_files Src/rc/sxtalsoftsuite.rc Src/rc/sxtalsoftsuite_rc.f90
Src/sxtalsoftsuite_gui.f90 Src/sxtalsoftsuite.f90)
include_directories($ENV{WINTER}/lib.if8)
add_executable(sxtalsoftsuite ${source_files})
target_link_libraries(sxtalsoftsuite $ENV{WINTER}/lib.if8/winter.lib)
###
I also read that there was a bug
(http://www.cmake.org/Bug/view.php?id=4068) with CMake concerning
ignored rc files without warning.
Does my case fall in that category ?
Would you have any hint to circumvent that problem ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] Problem using Lahey Fortran Compiler
Hello everybody, I would like to build a Fortran static library using the Lahey Fortran Compiler. When building my project with the following command: cmake -G NMake Makefiles -D CMAKE_Fortran_COMPILER=lf95 .. --debug-trycompile the build crash with the following starting line: -- The Fortran compiler identification is unknown -- Check for working Fortran compiler: C:/LF9556/Bin/lf95.exe -- Check for working Fortran compiler: C:/LF9556/Bin/lf95.exe -- broken CMake Error at C:/CMake2.8/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40 (MESSAGE): The Fortran compiler C:/LF9556/Bin/lf95.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Datas/Eclipse_Projects/Fortran/crysfml/build/lf95_release/CMakeFiles/CMakeTmp So it seems that the building was not able to even pass the testing step. What I do not understand is: - why the compiler identification is unknown as Lahey compiler is normally supported by CMake ? Is it really supported ? - why the test crashed as when I go to the CMakeTmp directory and run explicitely the compilation of the test program (BTW a simple hello world) the compilation works ? any idea thansks Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Merge two static libraries
Hello everybody, I have a library that can be built for a use in different modes (console, window). It is made of two sets of files. The first one is common to the console/window building modes while the second set has to be be built with a slightly different compiler flags depending on the selected building mode. After many discussions here, I was advised to build a static library for the the files common to console and window building modes (e.g. common.a) and to build a second static library for the files depending on the building mode (e.g. console.a and window.a) linking the latter to the first one. I did it and ... it worked ! But what I would like is a little bit different. I would like my console.a (or window.a) library to contain the object files of the common.a library. Indeed something like 'ar cr console.a library.a'. Would you have any idea ? thank you Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] Merge two static libraries
in fact the makefile we would like to generate should be able to:
- build the console version of library (-DBUILD_WINDOW=False)
- build the console AND the window versions of the library
(-DBUILD_WINDOW=True)
this is the latter case that triggered my questions.
Considering that only 2 files out of 50 will have a different
compilation flag between the console and window mode, that
would be a pity to duplicate the compilation of the 48 common sources
files. That's why I was looking for a way to produce:
- once the 48 objects files common to console and window building modes
- twice the 2 object files specific to the building mode:
* once in the console mode
* once in the window mode
- make a static library for the console mode
- make a static library for the window mode
That's why to do so, I planned to build:
- a static library for the 48 common files -- common.a
- a static library for the 2 specific files in console mode in which
I would have inserted common.a
- a static library for the 2 specific files in window mode in which
I would have inserted common.a
but failed to perform the insertion step ...
Marcel Loose a écrit :
On 5-10-2010 at 10:10, in message 4caadd79.7000...@ill.fr,
pellegrini
pellegr...@ill.fr wrote:
Hello everybody,
I have a library that can be built for a use in different modes
(console, window). It is made of two sets of files. The first one is
common to
the console/window building modes while the second set has to be be
built with a slightly different compiler flags depending on the
selected
building mode.
After many discussions here, I was advised to build a static library
for the the files common to console and window building modes
(e.g. common.a) and to build a second static library for the files
depending on the building mode (e.g. console.a and window.a) linking
the
latter to the first one. I did it and ... it worked ! But what I
would
like is a little bit different. I would like my console.a (or
window.a)
library to
contain the object files of the common.a library. Indeed something
like
'ar cr console.a library.a'.
Would you have any idea ?
thank you
Eric
Hi Eric,
My first question is: why do you want to join these two libraries. I
understand from your mail that people suggested you to create two
separate libraries. Now you want to join them again.
To answer your question: you can't join two static libraries, not in a
portable way. You should specify a complete list of sources in your
CMakeLists.txt file for each of the two libraries. Something like:
SET(LIB_SOURCES common.c)
IF(BUILD_CONSOLE)
LIST(APPEND LIB_SOURCES console.c)
ADD_LIBRARY(console ${LIB_SOURCES})
ELSEIF(BUILD_WINDOW)
LIST(APPEND LIB_SOURCES window.c)
ADD_LIBRARY(window ${LIB_SOURCES})
ENDIF(BUILD_CONSOLE)
The downside to this solution is that you have duplicates of the object
files that are part of common, but that's the price you'll have to pay
if you want to have just one static library.
HTH,
Marcel Loose.
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] Merge two static libraries
Hi Marcel,
I want a single library for respectively console and window modes
because I was asked to not disrupt too much the current architecture
of the library that is created in its console and window static version.
That library (crysfml) is used by other softs and so we should also
update their installers.
Currently, the library has even no makefiles. To build it you start a
script (e.g. install.sh window) that will:
- compile the 50 files for a further use of the library for programs
in console mode (console.a)
- compile again the 50 files for a further use of the library for
programs in window mode (window.a)
Everytime, you change any file in the library, you have to redo all the
process ... quite boring ...
That's why, I wanted to introduce a makefile, but a clever one that,
when using -DBUILD_WINDOW=True, would not recompile twice
the common files between the console and window modes.
I hope that I was a little be clearer.
thanks for your help
Marcel Loose a écrit :
Hi Eric,
I still don't understand why you want to have just one library. What's
wrong with having a common library, containing all the common software
and a console/window specific library?
You could also use shared libraries (DLLs), but I guess that's out of
the question for you, since you've been talking about static libraries
only.
Best regards,
Marcel Loose.
On Tue, 2010-10-05 at 10:45 +0200, pellegrini wrote:
in fact the makefile we would like to generate should be able to:
- build the console version of library (-DBUILD_WINDOW=False)
- build the console AND the window versions of the library
(-DBUILD_WINDOW=True)
this is the latter case that triggered my questions.
Considering that only 2 files out of 50 will have a different
compilation flag between the console and window mode, that
would be a pity to duplicate the compilation of the 48 common sources
files. That's why I was looking for a way to produce:
- once the 48 objects files common to console and window building modes
- twice the 2 object files specific to the building mode:
* once in the console mode
* once in the window mode
- make a static library for the console mode
- make a static library for the window mode
That's why to do so, I planned to build:
- a static library for the 48 common files -- common.a
- a static library for the 2 specific files in console mode in which
I would have inserted common.a
- a static library for the 2 specific files in window mode in which
I would have inserted common.a
but failed to perform the insertion step ...
Marcel Loose a écrit :
On 5-10-2010 at 10:10, in message 4caadd79.7000...@ill.fr,
pellegrini
pellegr...@ill.fr wrote:
Hello everybody,
I have a library that can be built for a use in different modes
(console, window). It is made of two sets of files. The first one is
common to
the console/window building modes while the second set has to be be
built with a slightly different compiler flags depending on the
selected
building mode.
After many discussions here, I was advised to build a static library
for the the files common to console and window building modes
(e.g. common.a) and to build a second static library for the files
depending on the building mode (e.g. console.a and window.a) linking
the
latter to the first one. I did it and ... it worked ! But what I
would
like is a little bit different. I would like my console.a (or
window.a)
library to
contain the object files of the common.a library. Indeed something
like
'ar cr console.a library.a'.
Would you have any idea ?
thank you
Eric
Hi Eric,
My first question is: why do you want to join these two libraries. I
understand from your mail that people suggested you to create two
separate libraries. Now you want to join them again.
To answer your question: you can't join two static libraries, not in a
portable way. You should specify a complete list of sources in your
CMakeLists.txt file for each of the two libraries. Something like:
SET(LIB_SOURCES common.c)
IF(BUILD_CONSOLE)
LIST(APPEND LIB_SOURCES console.c)
ADD_LIBRARY(console ${LIB_SOURCES})
ELSEIF(BUILD_WINDOW)
LIST(APPEND LIB_SOURCES window.c)
ADD_LIBRARY(window ${LIB_SOURCES})
ENDIF(BUILD_CONSOLE)
The downside to this solution is that you have duplicates of the object
files that are part of common, but that's the price you'll have to pay
if you want to have just one static library.
HTH,
Marcel Loose.
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com
[CMake] Build several libraries with different compilation flags
Hello everybody, I would like to build two libraries that contain the same files but with a slightly different set of compilation flags from one library to another. This within the same makefile. I was thinking about an approach such as: add_library(my_lib1, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) add_library(my_lib2, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) does cmake sensitive to the order of these instruction ? thank you very much Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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] Build several libraries with different compilation flags
Hi Ryan, Yes, that might be the solution if I wanted to change the compiler flags for the whole library but in my case, that is not on the whole library that I want to apply a new set of compiler flags but only on a small number of files. Ryan Pavlik a écrit : Look at the target properties instead of the source file properties. Ryan On 10/01/2010 08:27 AM, pellegrini wrote: Hello everybody, I would like to build two libraries that contain the same files but with a slightly different set of compilation flags from one library to another. This within the same makefile. I was thinking about an approach such as: add_library(my_lib1, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) add_library(my_lib2, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) does cmake sensitive to the order of these instruction ? thank you very much Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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] Build several libraries with different compilation flags
Hi Marcel, Yes, you are right but as I said to Ryan my problem is that I do not want to change the compiler flags for the whole library (in that case the set_target_properties would be the appropriated way to do) but only for a few files of my library. What I want to do seems tricky (or perhaps non sense ?). What about the following approach ? I will create two separate projects that I will call in my main CMakeLists.txt on the following way: project(my_whole_project Fortran) include(my_first_project) include(my_second_project) ... In doing so, each project does not see the other one (I hope) and I should be able to do whatever I want with one without disturbing the other. What do you think ?. Eric Marcel Loose a écrit : Hi Eric, I'm not sure your solution is going to work. Once your file1, file2, ... are compiled for building my_lib1, there's reason for CMake to compile them again for my_lib2, because the object files are already up-to-date. I guess you'll have a better chance using target_properties, as Ryan suggested. HTH, Marcel Loose. On Fri, 2010-10-01 at 17:10 +0200, pellegrini wrote: Hi Ryan, Yes, that might be the solution if I wanted to change the compiler flags for the whole library but in my case, that is not on the whole library that I want to apply a new set of compiler flags but only on a small number of files. Ryan Pavlik a écrit : Look at the target properties instead of the source file properties. Ryan On 10/01/2010 08:27 AM, pellegrini wrote: Hello everybody, I would like to build two libraries that contain the same files but with a slightly different set of compilation flags from one library to another. This within the same makefile. I was thinking about an approach such as: add_library(my_lib1, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) add_library(my_lib2, STATIC, src_files ...) set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS ...) does cmake sensitive to the order of these instruction ? thank you very much Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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 do not read my ifort compiler fllags
Hello everybody, I would like to set my own compiler flags to compile a library using intel fortran compiler. To do so, I created in my Src/ directory a Compiler/Intel-Fortran.cmake file that contains my preferences such as: SET(CMAKE_BUILD_TYPE_INIT Release) SET(CMAKE_Fortran_FLAGS_INIT ) SET(CMAKE_Fortran_FLAGS_DEBUG_INIT /debug:full /check /traceback /nologo) SET(CMAKE_Fortran_FLAGS_MINSIZEREL_INIT /O2 /nologo /Qvec-report0) SET(CMAKE_Fortran_FLAGS_RELEASE_INIT /O2 /nologo /Qvec-report0) SET(CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT /O2 /nologo /traceback /debug:full) SET(CMAKE_Fortran_MODDIR_FLAG -module ) SET(CMAKE_Fortran_VERBOSE_FLAG -v) but, when running cmake and then nmake, the compiler flags used are not the ones I set but the default ones. I do not understand because I used to do the same with g95 and it worked perfectly. By the way, the flags used seem to be the ones set in the Modules/Platform/Windows-ifort.cmake cmake distribution, as if that file was parsed instead of mine ! would you have any idea ? thanks Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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 do not read my ifort compiler fllags - correct version
Hello everybody, I would like to set my own compiler flags to compile a library using intel fortran compiler. To do so, I created in my Src/ directory a Compiler/Intel-Fortran.cmake file that contains my preferences such as: SET(CMAKE_BUILD_TYPE_INIT Release) SET(CMAKE_Fortran_FLAGS_INIT ) SET(CMAKE_Fortran_FLAGS_DEBUG_INIT /debug:full /check /traceback /nologo) SET(CMAKE_Fortran_FLAGS_MINSIZEREL_INIT /O2 /nologo /Qvec-report0) SET(CMAKE_Fortran_FLAGS_RELEASE_INIT /O2 /nologo /Qvec-report0) SET(CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT /O2 /nologo /traceback /debug:full) SET(CMAKE_Fortran_MODDIR_FLAG -module ) SET(CMAKE_Fortran_VERBOSE_FLAG -v) but, when running cmake and then nmake, the compiler flags used are not the ones I set but the default ones. I do not understand because I used to do the same with g95 and it worked perfectly. By the way, the flags used seem to be the ones set in the Modules/Platform/Windows-ifort.cmake cmake distribution, as if that file was parsed instead of mine ! However, when I put a message(hello) inside my file, it appears when building the cmake files. would you have any idea ? thanks Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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 -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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 do not read my ifort compiler fllags - correct version
Marcel Loose a écrit :
On Wed, 2010-09-29 at 12:06 +0200, pellegrini wrote:
Hello everybody,
I would like to set my own compiler flags to compile a library using
intel fortran compiler.
To do so, I created in my Src/ directory a
Compiler/Intel-Fortran.cmake file that contains my preferences such
as:
SET(CMAKE_BUILD_TYPE_INIT Release)
SET(CMAKE_Fortran_FLAGS_INIT )
SET(CMAKE_Fortran_FLAGS_DEBUG_INIT /debug:full /check /traceback
/nologo)
SET(CMAKE_Fortran_FLAGS_MINSIZEREL_INIT /O2 /nologo /Qvec-report0)
SET(CMAKE_Fortran_FLAGS_RELEASE_INIT /O2 /nologo /Qvec-report0)
SET(CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT /O2 /nologo /traceback
/debug:full)
SET(CMAKE_Fortran_MODDIR_FLAG -module )
SET(CMAKE_Fortran_VERBOSE_FLAG -v)
but, when running cmake and then nmake, the compiler flags used are
not
the ones I set but the default ones. I do not
understand because I used to do the same with g95 and it worked
perfectly. By the way, the flags used seem to be the ones
set in the Modules/Platform/Windows-ifort.cmake cmake distribution,
as if that file was parsed instead of mine ! However, when I put a
message(hello) inside my file, it appears when building the cmake
files.
would you have any idea ?
thanks
Eric
Hi Eric,
Just when exactly do you set these variables. As the name of these
variables suggest, these are initialisation variables. When CMake
processes the PROJECT() command, it also configures the compilers that
you define there (C and C++ by default). After that, none of the changes
you make to these *_INIT variables will be picked up.
HTH,
Marcel Loose.
Hi Marcel,
In fact my CMakeLists.txt file starts with the following lines:
cmake_minimum_required(VERSION 2.6.2)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
project(my_project Fortran)
in that case I have the problem described previously e.g. the
Compiler/G95-Fortran.cmake file is actually parsed but its contents not
used.
If I try in the following order:
cmake_minimum_required(VERSION 2.6.2)
project(my_project Fortran)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
the file is even not parsed at all.
--
Eric Pellegrini
Calcul Scientifique
Insitut Laue-Langevin
Grenoble, France
___
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] linker associated to ifort fortran compiler
Hello everybody, I would like to compile my project using intel fortran compiler on my windows machine. When running the following commands: cmake -DCMAKE_Fortran_Compiler=ifort -GNMake Makefiles nmake VERBOSE=1 I can see that nmake use the linker 'lib' provided with the intel fortran compiler. But, looking at my generated CMakeCache.txt I see just at the beginning: CMAKE_AR:FILEPATH=C:/MinGW/bin/ar.exe (I have the Mingw tools installed on my machine Two questions: - why cmake uses the 'lib' linker if another one was set in the CMakeCache.txt file ? - as it actually uses 'lib', how cmake did find the appropriated linker ? thanks Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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] Overriding intel default compiler flags
Hello everybody,
I come back with a question I asked yesterday but that I surely
misformulated. In the meantime I turned around
the problem all the day but still without any results ...
I would like to build my project using ifort fortran compiler with a set
of compiler flags different from the
ones set by default by cmake in the Windows-ifort.cmake file of the
distribution.
I was advised on the list to not introduce any specific compiler flags
declaration in my CMakeLists.txt and to
introduce in my Src directory a Compiler/Intel-Fortran.cmake file
storing the following compiler flags I would like to be
the default ones:
SET(CMAKE_BUILD_TYPE_INIT Release)
SET(CMAKE_Fortran_FLAGS_INIT )
SET(CMAKE_Fortran_FLAGS_DEBUG_INIT /debug:full /check /traceback
/nologo)
SET(CMAKE_Fortran_FLAGS_MINSIZEREL_INIT /O2 /nologo /Qvec-report0)
SET(CMAKE_Fortran_FLAGS_RELEASE_INIT /O2 /nologo /Qvec-report0)
SET(CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT /O2 /nologo /traceback
/debug:full)
Now my CMakeLists.txt file starts with:
cmake_minimum_required(VERSION 2.6.2)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
project(my_library Fortran)
Problem:
in doing so, cmake actually parses my Intel-Fortran.cmake file but all
the variables stored in there are subsequently replaced by the
values stored in Windows-ifort.cmake during the project call. This
does not happen when using the G95 to build my project because none
of these variables are set in the Windows-G95-Fortran.cmake file (and
its dependancies).
Is that a known bug for intel fortran compiler ? Would you see any
work-around or should I introduce in the CMakeLists a conditional for intel
compiler breaking in that special case one of the cmake programming
rules ? !
thanks for your help
Eric
--
Eric Pellegrini
Calcul Scientifique
Insitut Laue-Langevin
Grenoble, France
___
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] Build library with specific compil flags for a few files
Hello everybody, I have a library for which almost all the files should be compiled (e.g. g95) with the same compilation flags (that I will call later flag_debug, flag_release ...) excepted a few ones for which I have to use slightly different compilation flags (called later flag1_debug, flag1_release ...). As in both cases the flags are different from the default ones, I was told on the cmake list to create a personal Compiler/G95-Fortran.cmake file that was placed in my Src directory and that contains the following lines: set(CMAKE_Fortran_FLAGS_INIT ) set(CMAKE_Fortran_FLAGS_DEBUG_INIT flag_debug) set(CMAKE_Fortran_FLAGS_RELEASE_INIT flag_release) set(CMAKE_Fortran_MODDIR_FLAG -fmod=) set(CMAKE_Fortran_VERBOSE_FLAG -v) This file allowing to avoid the declaration of the flags in the CMakeLists.txt file. But, how to proceed for the few files for which I have to use different compiler flags ? In that case, I do not see any way to escape from writing specifically the flags in the CMakeLists.txt file with command such as: if(CMAKE_BUILD_TYPE STREQUAL RELEASE) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_release) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_release) ... elseif(CMAKE_BUILD_TYPE STREQUAL DEBUG) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_debug) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_debug) ... ... endif() would you have any idea about how to esacpe from this kind of implementation ? is that so ugly ? thanks Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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] Build library with specific compil flags for a few files
Hi Michael, so if I get you right I should organize my library as follow: src/ Compiler/G95_Fortran.cmake CMakeLists.txt my_general_f90_src_files special_flag_src/ Compiler/G95_Fortran.cmake CMakeLists.txt my_special_f90_src_files where the nested CMakeLists.txt will call add_library(my_special_f90_files.a my_special_f90_src_files ...) and where the main CMakeLists.txt file will call add_library(my_general_f90_files.a my_general_f90_src_files ...) not forgotting in the latter case to specify the dependancy on the special_f90_files.a library. In doing so, both static libraries will be compiled according to the compilation flags stored in their respective Compiler/G95_Fortran.cmake files. sorry for the naive questions but I just started with CMake two weeks ago and I am quite in hurry to provide a first example to convince my boss that using CMake is the right solution ... thanks again Eric On 28. Sep, 2010, at 16:08 , pellegrini wrote: Hello everybody, I have a library for which almost all the files should be compiled (e.g. g95) with the same compilation flags (that I will call later flag_debug, flag_release ...) excepted a few ones for which I have to use slightly different compilation flags (called later flag1_debug, flag1_release ...). As in both cases the flags are different from the default ones, I was told on the cmake list to create a personal Compiler/G95-Fortran.cmake file that was placed in my Src directory and that contains the following lines: set(CMAKE_Fortran_FLAGS_INIT ) set(CMAKE_Fortran_FLAGS_DEBUG_INIT flag_debug) set(CMAKE_Fortran_FLAGS_RELEASE_INIT flag_release) set(CMAKE_Fortran_MODDIR_FLAG -fmod=) set(CMAKE_Fortran_VERBOSE_FLAG -v) This file allowing to avoid the declaration of the flags in the CMakeLists.txt file. But, how to proceed for the few files for which I have to use different compiler flags ? In that case, I do not see any way to escape from writing specifically the flags in the CMakeLists.txt file with command such as: if(CMAKE_BUILD_TYPE STREQUAL RELEASE) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_release) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_release) ... elseif(CMAKE_BUILD_TYPE STREQUAL DEBUG) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_debug) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_debug) ... ... endif() would you have any idea about how to esacpe from this kind of implementation ? is that so ugly ? thanks Eric Well, for one you don't need separate set_source_files_properties commands for every single file (that is, if the flags are the same): if(CMAKE_BUILD_TYPE STREQUAL Release) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) elseif(CMAKE_BUILD_TYPE STREQUAL Debug) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) endif() However: such a scheme will break with multi-configuration IDEs since CMAKE_BUILD_TYPE is not known when CMake runs because the user can choose the configuration in the IDE afterwards. Unfortunately there are no COMPILE_FLAGS_CONFIG properties... I think that currently the only reliable way of doing this is to split the special sources out into a separate directory and compile them there as a static library. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken ___ 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] set_target_properties versus set_source_files_properties
Hello everybody,
my question is in the title !
I want to create a fortran static library using the following set of g95
compiler flags -O3 -std=f2003 -funroll-loops -msse2
If I use:
set_target_properties(my_static_lib PROPERTIES COMPILE_FLAGS -O3
-std=f2003 -funroll-loops -msse2)
or
set_source_files_properties(${SRC_FILES} PROPERTIES COMPILE_FLAGS -O3
-std=f2003 -funroll-loops -msse2)
where ${SRC_FILES} is the list of source files used to compile my static
library, the result is the same when starting the make process.
So, in such a case is there a difference between those two functions ?
Another question I have is when applying one or the other function, this
will duplicate some of the compiler flags (e.g. O3). The only way I
found to avoid this is to do the following:
set(CMAKE_Fortran_FLAGS_RELEASE )
set_target_properties(crysfml PROPERTIES COMPILE_FLAGS -O3 -std=f2003
-funroll-loops -msse2)
so everything looks as if by default the CMAKE_Fortran_FLAGS_RELEASE
variable was set to -O3 and then, the value stored in the
COMPILE_FLAGS variable was appended to it (so in that case -O3 + -O3
-std=f2003 -funroll-loops -msse2 giving -O3 -O3 -std=f2003
-funroll-loops -msse2). Am I right ?
thanks a lot
Eric
--
Eric Pellegrini
Calcul Scientifique
Insitut Laue-Langevin
Grenoble, France
___
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
