Re: [CMake] Include-Dir order problem
On 16.02.11 03:48:03, Michael Hertling wrote:
> On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
> > On 15.02.11 17:54:29, Michael Hertling wrote:
> >> On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
> >>> Hi,
> >>>
> >>> I've got a somewhat tricky problem here with include directories. I'm
> >>> building a couple of source files and for some of them I need to add an
> >>> include-directory to the front of the list that cmake passes to the
> >>> compiler. At the same time other source files in that directory need to
> >>> not have that include-dir in front of the list.
> >>>
> >>> I can't see a way to do this, except by using COMPILE_FLAGS source file
> >>> properties for each and every file to specify include-dirs and not use
> >>> include_directories at all, as COMPILE_FLAGS always end up behind the
> >>> includes.
> >>>
> >>> So, am I missing something here? If not I guess I'll have to find that
> >>> bugreport about making include-dirs a source-file property and vote for
> >>> it so it gets included into 2.8.5...
> >>
> >> Currently, AFAIK, it's not possible to set source-file-specific include
> >> directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
> >> the shortcoming you've mentioned. Probably, the really clean solution
> >> ATM would be a reorganisation of the sources, but I doubt if the need
> >> for different include directories is an appropriate criterion for a
> >> project's directory layout.
> >
> > Well, all those sources need to be in the same target, so I can't quite
> > see how moving some of the sources into subdirs wuld help with that.
>
> Look at the following CMakeLists.txt files:
>
> # CMakeLists.txt:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(INCLUDEDIRECTORIES C)
> ADD_SUBDIRECTORY(subdir)
> INCLUDE_DIRECTORIES(abc)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){f();return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> TARGET_LINK_LIBRARIES(main sub)
>
> # subdir/CMakeLists.txt:
> INCLUDE_DIRECTORIES(xyz)
> FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c "void f(void){}\n")
> ADD_LIBRARY(sub STATIC f.c)
>
> So, main.c and f.c are compiled with different include directories, but
> the "main" target is effectively composed from the same object files as
> if f.c had been explicitly mentioned among the source files for "main".
> If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
> in the top-level CMakeLists.txt, the include directories for main.c will
> also hold for f.c while the latter still has its own - additional - ones.
>
> Things become worse if the target to be built is a shared library.
Exactly my case.
> Most probably, you don't want an additional libsub.so, so you would
> need to compile f.c at least with "-fPIC" as COMPILE_FLAGS to get
> further along with a static library. Alternatively, you might use a
> RULE_LAUNCH_LINK property in order to capture the object files from
> the subdirectory and incorporate them in the actual target, see [1].
> However, then you would be restricted to a Makefile generator. IMO,
> none of these appoaches is really convincing why one should aim at an
> INCLUDE_DIRECTORIES source file and target property.
Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.
Andreas
--
Your object is to save the world, while still leading a pleasant life.
___
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] detecting build configuration in Visual Studio
Many thanks for your valuable feedback.
I will be trying this solution out.
Regards,
Dominik
On Wed, Feb 16, 2011 at 2:33 AM, Michael Hertling wrote:
> On 02/15/2011 03:49 PM, Dominik Szczerba wrote:
>> In MSVC I need to link different libraries depending on the chosen
>> build type. I have two questions:
>>
>> 1) If and how can I register my own build types
>
>>> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_specify_my_own_configurations_.28for_generators_that_allow_it.29_.3F
>
>> 2) How can I detect which one I am in for conditional linking
>
> AFAIK, you can't, but you might do the following: Declare the differing
> libraries for the different configurations as IMPORTED libraries and
> set the IMPORTED_LOCATION_ properties accordingly, e.g.:
>
> ADD_LIBRARY(xyz SHARED IMPORTED)
> SET_TARGET_PROPERTIES(xyz PROPERTIES
> IMPORTED_LOCATION_CUSTOMIZED "..."
> IMPORTED_LOCATION_RELEASE "..."
> IMPORTED_LOCATION_DEBUG "..."
> ...
> )
> ...
> TARGET_LINK_LIBRARIES(... xyz ...)
>
> If such a library should not be taken into account for a particular
> configuration at all, things are more complex since you can't declare
> an empty IMPORTED_LOCATION. A possible approach might look as follows:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(IMPORTEDDUMMY C)
> ADD_LIBRARY(dummy STATIC "")
> SET_TARGET_PROPERTIES(dummy PROPERTIES LINKER_LANGUAGE C)
> EXPORT(TARGETS dummy NAMESPACE imported FILE importeddummy.cmake)
> INCLUDE(${CMAKE_BINARY_DIR}/importeddummy.cmake)
> SET_TARGET_PROPERTIES(importeddummy PROPERTIES
> IMPORTED_LINK_INTERFACE_LIBRARIES_CUSTOMIZED "..."
> )
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> TARGET_LINK_LIBRARIES(main importeddummy)
>
> The target "dummy" is an empty static library and needed as anchor for
> an imported static library "importeddummy" which refers to the former;
> this is achieved by EXPORT() and the generated "importeddummy.cmake"
> file. Finally, the importeddummy target is associated with additional
> libraries via the IMPORTED_LINK_INTERFACE_LIBRARIES_ property.
> This property is the reason for the intermediate importeddummy target
> since it can't be imposed on non-imported ones. At the end of the day,
> the additional libraries appear in the link command line only for the
> CUSTOMIZED configuration. Maybe, it would be worth a feature request
> to drop an imported library from the link command line completely if
> there's no IMPORTED_LOCATION for the active configuration instead of
> having "make" raise an error.
>
> 'hope that helps.
>
> 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
>
>
___
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 and OpenSSL libraries
Yeah, Qt uses them as plugins by default so BundleUtilities won't pick it up. You could also copy it manually like other Qt plugins, or configure Qt with the -openssl-link flag so it can copy the library for you. Clint - Reply message - From: "Crni Gorac" Date: Tue, Feb 15, 2011 3:38 pm Subject: [CMake] CPack and OpenSSL libraries To: Am using CPack to create Windows and Mac installers for an application. The application is Qt based, and BundleUtilities is working great for me to pick up dependencies and such. However, I have problem that OpenSSL libraries, which are needed for some segments of functionality of my app, are not picked up. I guess Qt network module is using these libraries as plugins, which means it is checking in run time are libraries present on the target system or not, and is loading them dynamically if so. I have no problems with my Mac installer in that regard, as it seems on Mac machines OpenSSL libraries are installed by default, so my application is able to pick them up at run time. However, for the Windows installer, I'll guess I'll have to pick them somehow. So I was just wondering has anyone encountered this problem so far, and what would be preferred solution with CMake/CPack (to utilize FindOpenSSL.cmake and then explicitly link my app with OpenSSL libraries, or maybe something else)? Thanks. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Include-Dir order problem
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
> On 15.02.11 17:54:29, Michael Hertling wrote:
>> On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
>>> Hi,
>>>
>>> I've got a somewhat tricky problem here with include directories. I'm
>>> building a couple of source files and for some of them I need to add an
>>> include-directory to the front of the list that cmake passes to the
>>> compiler. At the same time other source files in that directory need to
>>> not have that include-dir in front of the list.
>>>
>>> I can't see a way to do this, except by using COMPILE_FLAGS source file
>>> properties for each and every file to specify include-dirs and not use
>>> include_directories at all, as COMPILE_FLAGS always end up behind the
>>> includes.
>>>
>>> So, am I missing something here? If not I guess I'll have to find that
>>> bugreport about making include-dirs a source-file property and vote for
>>> it so it gets included into 2.8.5...
>>
>> Currently, AFAIK, it's not possible to set source-file-specific include
>> directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
>> the shortcoming you've mentioned. Probably, the really clean solution
>> ATM would be a reorganisation of the sources, but I doubt if the need
>> for different include directories is an appropriate criterion for a
>> project's directory layout.
>
> Well, all those sources need to be in the same target, so I can't quite
> see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){f();return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the "main" target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for "main".
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library. Most
probably, you don't want an additional libsub.so, so you would need to
compile f.c at least with "-fPIC" as COMPILE_FLAGS to get further along
with a static library. Alternatively, you might use a RULE_LAUNCH_LINK
property in order to capture the object files from the subdirectory and
incorporate them in the actual target, see [1]. However, then you would
be restricted to a Makefile generator. IMO, none of these appoaches is
really convincing why one should aim at an INCLUDE_DIRECTORIES source
file and target property.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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] detecting build configuration in Visual Studio
On 02/15/2011 03:49 PM, Dominik Szczerba wrote:
> In MSVC I need to link different libraries depending on the chosen
> build type. I have two questions:
>
> 1) If and how can I register my own build types
>> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_specify_my_own_configurations_.28for_generators_that_allow_it.29_.3F
> 2) How can I detect which one I am in for conditional linking
AFAIK, you can't, but you might do the following: Declare the differing
libraries for the different configurations as IMPORTED libraries and
set the IMPORTED_LOCATION_ properties accordingly, e.g.:
ADD_LIBRARY(xyz SHARED IMPORTED)
SET_TARGET_PROPERTIES(xyz PROPERTIES
IMPORTED_LOCATION_CUSTOMIZED "..."
IMPORTED_LOCATION_RELEASE "..."
IMPORTED_LOCATION_DEBUG "..."
...
)
...
TARGET_LINK_LIBRARIES(... xyz ...)
If such a library should not be taken into account for a particular
configuration at all, things are more complex since you can't declare
an empty IMPORTED_LOCATION. A possible approach might look as follows:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDDUMMY C)
ADD_LIBRARY(dummy STATIC "")
SET_TARGET_PROPERTIES(dummy PROPERTIES LINKER_LANGUAGE C)
EXPORT(TARGETS dummy NAMESPACE imported FILE importeddummy.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importeddummy.cmake)
SET_TARGET_PROPERTIES(importeddummy PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_CUSTOMIZED "..."
)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main importeddummy)
The target "dummy" is an empty static library and needed as anchor for
an imported static library "importeddummy" which refers to the former;
this is achieved by EXPORT() and the generated "importeddummy.cmake"
file. Finally, the importeddummy target is associated with additional
libraries via the IMPORTED_LINK_INTERFACE_LIBRARIES_ property.
This property is the reason for the intermediate importeddummy target
since it can't be imposed on non-imported ones. At the end of the day,
the additional libraries appear in the link command line only for the
CUSTOMIZED configuration. Maybe, it would be worth a feature request
to drop an imported library from the link command line completely if
there's no IMPORTED_LOCATION for the active configuration instead of
having "make" raise an error.
'hope that helps.
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
Re: [CMake] Setting target destination and rpath per generator
Thank you! I did not know about $ORIGIN but that is indeed exactly what I need.
From: Alexander Neundorf
To: cmake@cmake.org
Cc: Daryl N
Sent: Tue, February 15, 2011 3:45:25 PM
Subject: Re: [CMake] Setting target destination and rpath per generator
On Tuesday 15 February 2011, Daryl N wrote:
> Hi,
>
> I have a question on the use of CPack. I have CMake setup to generate
> binaries and shared libraries. Up until now I have only created a TGZ with
> rpath set to ".". This has worked nicely, but now I would like to create a
> Debian package for proper installation. I have added DEB to
> CPACK_GENERATOR and I've created my own cpack_config.cmake file. My goal
> is:
>
> 1. Run cmake/make package once and create the tar.gz file with all exe/libs
> in the root folder of the tar.gz file with rpath set to ".".
> 2. Create new .deb package with exes in /usr/local/bin and libs in
> /usr/local/lib. Alternatively, since files are private, all could be put
> in /usr/local/.
>
> I've attempted this by creating my own cpack_config.cmake file to try to
> override some settings per generator. Some observations:
>
> 1. I've been unable to set the install( DESTINATION) path per
> generator in my cpack_config.cmake file. Whatever the variable is set to
> when the install(...) is processed in the CMakeLists.txt file is what is
> used for all generators. Just want to confirm changing this isn't an
> option per generator.
>
> The above has prevented me from having my install lines like:
> install( DESTINATION ${BIN_PATH})
> install( DESTINATION ${LIB_PATH})
> and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
> them to "." for TGZ, since I can't change the variable in
> cpack_config.cmake.
Are you sure "." does what you want ? I can remember I tried it to, and didn't
what I needed, but I can't remember the details.
Do you know about $ORIGIN for the RPATH ? This means the location of the
containing ELF file.
Alex
___
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] Patch for watcom InstallRequiredSystemLibraries
http://public.kitware.com/Bug/view.php?id=11866 ___ 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] Cross compilation question
I haven't done anything with toolchains. I will take a look at the page and give it a go. Thanks, Steve On Tue, Feb 15, 2011 at 3:16 PM, Peter Kümmel wrote: > On 15.02.2011 22:52, Steven Wilson wrote: > >> In my CMake configuration files I have something like the following: >> >> >> if(SYSTEM STREQUAL "iOS") >> set(CMAKE_C_COMPILER "foo" CACHE STRING "message" FORCE) >> set(CMAKE_CXX_COMPILER "bar" CACHE STRING "message" FORCE) >> endif(SYSTEM STREQUAL "iOS") >> > > Do you know this wiki page: > http://www.cmake.org/Wiki/CMake_Cross_Compiling > > I never had such problems you describe by writing a small > toolchain file and initially pass it to cmake by -DCMAKE_TOOLCHAIN_FILE=... > > Later on I only call "cmake ." > > Peter > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and OpenSSL libraries
Download the latest ssl libs or which ever version you need. Then place them
in your QT libs dir (or any dir)and call it for install.
IF( WIN32 )
INSTALL(FILES
${CMAKE_CURRENT_SOURCE_DIR}/qtlibs/libeay32.DLL
${CMAKE_CURRENT_SOURCE_DIR}/vcredist/ssleay32.DLL
DESTINATION ${support_dest_dir}
COMPONENT Runtime
)
ENDIF( WIN32 )
--
View this message in context:
http://cmake.3232098.n2.nabble.com/CPack-and-OpenSSL-libraries-tp6029611p6029647.html
Sent from the CMake mailing list archive at Nabble.com.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack and OpenSSL libraries
Am using CPack to create Windows and Mac installers for an application. The application is Qt based, and BundleUtilities is working great for me to pick up dependencies and such. However, I have problem that OpenSSL libraries, which are needed for some segments of functionality of my app, are not picked up. I guess Qt network module is using these libraries as plugins, which means it is checking in run time are libraries present on the target system or not, and is loading them dynamically if so. I have no problems with my Mac installer in that regard, as it seems on Mac machines OpenSSL libraries are installed by default, so my application is able to pick them up at run time. However, for the Windows installer, I'll guess I'll have to pick them somehow. So I was just wondering has anyone encountered this problem so far, and what would be preferred solution with CMake/CPack (to utilize FindOpenSSL.cmake and then explicitly link my app with OpenSSL libraries, or maybe something else)? Thanks. ___ 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] Cross compilation question
On 15.02.2011 22:52, Steven Wilson wrote: In my CMake configuration files I have something like the following: if(SYSTEM STREQUAL "iOS") set(CMAKE_C_COMPILER "foo" CACHE STRING "message" FORCE) set(CMAKE_CXX_COMPILER "bar" CACHE STRING "message" FORCE) endif(SYSTEM STREQUAL "iOS") Do you know this wiki page: http://www.cmake.org/Wiki/CMake_Cross_Compiling I never had such problems you describe by writing a small toolchain file and initially pass it to cmake by -DCMAKE_TOOLCHAIN_FILE=... Later on I only call "cmake ." Peter ___ 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] Cross compilation question
In my CMake configuration files I have something like the following: if(SYSTEM STREQUAL "iOS") set(CMAKE_C_COMPILER "foo" CACHE STRING "message" FORCE) set(CMAKE_CXX_COMPILER "bar" CACHE STRING "message" FORCE) endif(SYSTEM STREQUAL "iOS") Then when configuring the system I pass -DSYSTEM:STRING=iOS on the command line (or through a GUI). For my iOS system I use the makefile generator. Steve 2011/2/15 Alexander Neundorf > On Monday 14 February 2011, Steven Wilson wrote: > > My apologies if this question has been asked and answered previously. > I > > have a CMake system that I use for cross compilation for iOS software (ie > > reset CMAKE_C_COMPILER, etc...). > > How do you do that ? > You have to set CMAKE_C_COMPILER, CMAKE_CXX_COMPILER and CMAKE_SYSTEM_NAME. > And they have to be set so that they stay the same later on, e.g. by using > a "toolchain file". > > Do you do it that way or in some other way ? > > Do you use the makefile generator or xcode ? > > Alex > ___ 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] Cross-compiling: Cmake compiler and ABI check don´t work
Hi, On Friday 11 February 2011, Schmid Alexander wrote: > Hi, > > > > I am working with CMake 2.8.3 and trying to set up a cross-compiling > toolchain for an ARMCC that runs on a Windows system. > > > > What I´ve done up to now is that I set up a toolchain file that I am using > in combination with nmake makefiles. Can you please post the complete toolchain file ? Maybe there's something unusual in it. Alex ___ 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] Naive (stupid?) question
Hello, apologies for the stupid question. I have a large project and at times a change triggers unexpected consequences, i.e. very large recompilations, rebuild of the cmake makefiles and so on. Is there a way in cmake to understand why things happens? I mean which chain of dependencies causes a given action to be taken? It would be for me very interesting to understand something more about the dependencies in my project, to be able to reduce them. Thanks and best regards, Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 68505 Mobile: +41 76 487 4843 ___ 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] 2.8.5 version
2011/2/15 Alexander Neundorf > On Monday 14 February 2011, David Cole wrote: > > On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi > wrote: > > > I'm very interested in the feature discussed here: > > > http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably > it > > > won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 > > > > will > > > > > be released? Or better, do you have a periodic schedule planning the > > > releases? > > > > > You are correct. We will be releasing 2.8.4 very shortly... > > > > We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 > > will be released in May, 2011. We'll probably schedule a "release > candidate > > 1" trial build for late April. > > I have a local fix for the mentioned issue, but I thought I should not try > to > merge it now into next, since it is more like a feature and less like a > bugfix. > But I can do it you you#re ok with it. > > Alex > You can push to the stage and merge to next whenever you like. That's one of the beauties of our new git workflow... ___ 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] Setting target destination and rpath per generator
On Tuesday 15 February 2011, Daryl N wrote:
> Hi,
>
> I have a question on the use of CPack. I have CMake setup to generate
> binaries and shared libraries. Up until now I have only created a TGZ with
> rpath set to ".". This has worked nicely, but now I would like to create a
> Debian package for proper installation. I have added DEB to
> CPACK_GENERATOR and I've created my own cpack_config.cmake file. My goal
> is:
>
> 1. Run cmake/make package once and create the tar.gz file with all exe/libs
> in the root folder of the tar.gz file with rpath set to ".".
> 2. Create new .deb package with exes in /usr/local/bin and libs in
> /usr/local/lib. Alternatively, since files are private, all could be put
> in /usr/local/.
>
> I've attempted this by creating my own cpack_config.cmake file to try to
> override some settings per generator. Some observations:
>
> 1. I've been unable to set the install( DESTINATION) path per
> generator in my cpack_config.cmake file. Whatever the variable is set to
> when the install(...) is processed in the CMakeLists.txt file is what is
> used for all generators. Just want to confirm changing this isn't an
> option per generator.
>
> The above has prevented me from having my install lines like:
> install( DESTINATION ${BIN_PATH})
> install( DESTINATION ${LIB_PATH})
> and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
> them to "." for TGZ, since I can't change the variable in
> cpack_config.cmake.
Are you sure "." does what you want ? I can remember I tried it to, and didn't
what I needed, but I can't remember the details.
Do you know about $ORIGIN for the RPATH ? This means the location of the
containing ELF file.
Alex
___
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] Cross compilation question
On Monday 14 February 2011, Steven Wilson wrote: > My apologies if this question has been asked and answered previously.I > have a CMake system that I use for cross compilation for iOS software (ie > reset CMAKE_C_COMPILER, etc...). How do you do that ? You have to set CMAKE_C_COMPILER, CMAKE_CXX_COMPILER and CMAKE_SYSTEM_NAME. And they have to be set so that they stay the same later on, e.g. by using a "toolchain file". Do you do it that way or in some other way ? Do you use the makefile generator or xcode ? Alex ___ 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] 2.8.5 version
On Monday 14 February 2011, David Cole wrote: > On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi wrote: > > I'm very interested in the feature discussed here: > > http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it > > won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 > > will > > > be released? Or better, do you have a periodic schedule planning the > > releases? > > > You are correct. We will be releasing 2.8.4 very shortly... > > We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 > will be released in May, 2011. We'll probably schedule a "release candidate > 1" trial build for late April. I have a local fix for the mentioned issue, but I thought I should not try to merge it now into next, since it is more like a feature and less like a bugfix. But I can do it you you#re ok with it. Alex ___ 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] Simple (?) problem with libraries & executable dependencies
On Tuesday 15 February 2011, Carminati Federico wrote:
> Hello Michael,
>thanks a lot for looking into my problem. It turns out that Mac OS X
> behaves a bit oddly, in the sense that the name of the directory of
> installation is in the libraries as well as in the executable. I solved the
> problem with a single line setting the properties of the library in the
> following way:
>
> set_target_properties(${PACKAGE} PROPERTIES INSTALL_NAME_DIR
> ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
That doesn't look right.
CMAKE_LIBRARY_OUTPUT_DIRECTORY is the directory where the library is built,
not the directory where it is installed to.
Is libMUONevaluation.so actually getting installed or is that an old version
which is already in /usr/local ?
Maybe it is not and the executable doesn't find it then, because it has not
been installed ?
Also, I thought on OSX it's DYLD_LIBRARY_PATH, and not LD_LIBRARY_PATH. AFAIK
you also don't have an RPATH, but instead INSTALL_NAME_DIR.
Alex
___
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] add_executable(...) with source from another path
On 2011-02-15 16:06-0200 Felipe Ferreri Tonello wrote:
Hello guys,
I'm new to CMake and I'm really enjoying it. Anyway.. I'm porting a gnu
makefile project to CMake and I need to compile 3 sources code to generate one
executable.
What's the better way to do that with CMake?
Use the full pathname for each src file. The predefined variable
${CMAKE_SOURCE_DIR} (see
http://www.cmake.org/Wiki/CMake_Useful_Variables) which points to the
top of the source tree is a big help here.
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
__
___
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 32bit rpm on a 64bit system
2011/2/15 Yngve Inntjore Levinsen : > Dear CMakers, > > I am trying to package a 32bit binary on a 64bit system. It breaks with the > (useless?) verbose output which follows below. What I could find of useful > information was in _CPack_Packages/Linux/RPM/rpmbuild.err, which stated > error: No compatible architectures found for build Which version of CMake/CPack ? > I tried to set CPACK_RPM_PACKAGE_ARCHITECTURE and CPACK_PACKAGE_ARCHITECTURE > to i686, but that didn't do much. I found that e.g. the TGZ generator works > just fine, so I suppose it is something with the RPM generator, but I am not > clever enough to figure out what... > > Can anyone help? Could you send me the log obtained with: cpack -V -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM and send me the advertised "rpmbuild.err, rpmbuild.out, .spec" files? Some more questions: What is your linux distribution ? How did you build the 32bits binaries with CMake (? add -m32 using CFLAGS?) ? RPM packaging of 32bits apps on 64bits may not be portable at all, why are you trying to do that ? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PATH issue in FindQt4.cmake
Hi All,
I reran my code using cmake 2.8.4rc and still get the same issue where
FIND_PATH is picking the system directory for QT_CORE over my install
directory passed through HINTS ${qt_headers}. If this is not related to
CMAKE_FIND_FRAMEWORK should I file a bug report on this?
Thanks,
Hari
On Tue, Feb 15, 2011 at 10:23 AM, Andreas Pakulat wrote:
> On 15.02.11 06:34:07, Harinarayan Krishnan wrote:
> > Hi All,
> >
> > Thanks for the help so far, I will check and see if CMake 2.8.4rc has the
> > same issue meanwhile I noticed that FIND_PATH seems to have special
> > instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on
> > page
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path
> >
> > The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults
> to
> > "FIRST" on Darwin systems which I can interpret one of two ways.
> >
> > First, If a standard library and a framework are found in the same search
> > order then CMAKE will use this variable to determine which to pick first.
> >
> > Second, if a framework is found regardless of where it is in the search
> > order it will be picked. I suspect the choice is the first one. However,
> in
> > my test I found that if I set CMAKE_FIND_FRAMEWORK to be "LAST" then
> CMAKE
> > picks the proper path. This would make me think the second option is at
> play
> > or it is just pure coincidence that this option happened to give me the
> > correct result.
> >
> > Any of you know what the correct option is? To me it would make sense
> that
> > FIND_PATH honors the search order which would mean that the HINTS option
> in
> > FindQt4 should have higher precedence than the Framework in the
> > CMAKE_SYSTEM_FRAMEWORK_PATH.
>
> This cannot be answered without looking at the source code (as its not
> documented properly) to check what exactly the algorithm does. That is
> wether it iterates of the individual path in each of the steps and then
> checks for framework and afterwards for standard headers in that path or
> if it first checks all paths in a step for frameworks and then again
> checks all paths for standard headers. Depending on which of the two it
> is, the outcome of a find_path may depend on the order of the input
> path-variables (like CMAKE_PREFIX_PATH) or not.
>
> Andreas
>
> --
> You are the only person to ever get this message.
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Include-Dir order problem
On 15.02.11 17:54:29, Michael Hertling wrote: > On 02/13/2011 01:27 AM, Andreas Pakulat wrote: > > Hi, > > > > I've got a somewhat tricky problem here with include directories. I'm > > building a couple of source files and for some of them I need to add an > > include-directory to the front of the list that cmake passes to the > > compiler. At the same time other source files in that directory need to > > not have that include-dir in front of the list. > > > > I can't see a way to do this, except by using COMPILE_FLAGS source file > > properties for each and every file to specify include-dirs and not use > > include_directories at all, as COMPILE_FLAGS always end up behind the > > includes. > > > > So, am I missing something here? If not I guess I'll have to find that > > bugreport about making include-dirs a source-file property and vote for > > it so it gets included into 2.8.5... > > Currently, AFAIK, it's not possible to set source-file-specific include > directories unless one (mis)uses COMPILE_FLAGS which is accompanied by > the shortcoming you've mentioned. Probably, the really clean solution > ATM would be a reorganisation of the sources, but I doubt if the need > for different include directories is an appropriate criterion for a > project's directory layout. Well, all those sources need to be in the same target, so I can't quite see how moving some of the sources into subdirs wuld help with that. > If there're only a few affected files, another possible workaround > consists of file-specific configured headers, i.e. find the special > include directories and inject them into config'd headers that are > included by the concerned source files, or even modify the latters > themselves in this manner. Of course, the sources must be touched > to do that. Thats probably the route I'm going to take as indeed there are only few files needing the extra include at the front and it'll also solve the problem of new developers in the team not realizing that the header that is included is not the one they think it is... > IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be > also available as target and source file property, so I would vote > for 1968 and 8189 - seem to be relatives - and possibly 8874, too. > However, if this undertaking is addressed, one should think about > how the include directories are ordered on the compiler's command > line. Perhaps, there might be a convention that they appear from > most to least specific, i.e. in source-target-directory order. Thanks for digging up the bugnumbers for me. I've added my use-case there and will make sure to bring this up when the cmake devs gather input again for the next release... Andreas -- You will soon meet a person who will play an important role in your life. ___ 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] FIND_PATH issue in FindQt4.cmake
On 15.02.11 06:34:07, Harinarayan Krishnan wrote: > Hi All, > > Thanks for the help so far, I will check and see if CMake 2.8.4rc has the > same issue meanwhile I noticed that FIND_PATH seems to have special > instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on > page http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path > > The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults to > "FIRST" on Darwin systems which I can interpret one of two ways. > > First, If a standard library and a framework are found in the same search > order then CMAKE will use this variable to determine which to pick first. > > Second, if a framework is found regardless of where it is in the search > order it will be picked. I suspect the choice is the first one. However, in > my test I found that if I set CMAKE_FIND_FRAMEWORK to be "LAST" then CMAKE > picks the proper path. This would make me think the second option is at play > or it is just pure coincidence that this option happened to give me the > correct result. > > Any of you know what the correct option is? To me it would make sense that > FIND_PATH honors the search order which would mean that the HINTS option in > FindQt4 should have higher precedence than the Framework in the > CMAKE_SYSTEM_FRAMEWORK_PATH. This cannot be answered without looking at the source code (as its not documented properly) to check what exactly the algorithm does. That is wether it iterates of the individual path in each of the steps and then checks for framework and afterwards for standard headers in that path or if it first checks all paths in a step for frameworks and then again checks all paths for standard headers. Depending on which of the two it is, the outcome of a find_path may depend on the order of the input path-variables (like CMAKE_PREFIX_PATH) or not. Andreas -- You are the only person to ever get this message. ___ 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] add_executable(...) with source from another path
Hello guys, I'm new to CMake and I'm really enjoying it. Anyway.. I'm porting a gnu makefile project to CMake and I need to compile 3 sources code to generate one executable. What's the better way to do that with CMake? Thank you ___ 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 32bit rpm on a 64bit system
Dear CMakers, I am trying to package a 32bit binary on a 64bit system. It breaks with the (useless?) verbose output which follows below. What I could find of useful information was in _CPack_Packages/Linux/RPM/rpmbuild.err, which stated error: No compatible architectures found for build I tried to set CPACK_RPM_PACKAGE_ARCHITECTURE and CPACK_PACKAGE_ARCHITECTURE to i686, but that didn't do much. I found that e.g. the TGZ generator works just fine, so I suppose it is something with the RPM generator, but I am not clever enough to figure out what... Can anyone help? Cheers and thanks, Yngve > cpack -V -G RPM CPack: Enable Verbse CPack Verbose: Read CPack config file: CPack Verbose: Read CPack configuration file: /path/to/build/CPackConfig.cmake CPack Verbose: Specified generator: RPM CPack Verbose: Use generator: cmCPackRPMGenerator CPack Verbose: For project: madX CPack: Create package using RPM CPack Verbose: Read description file: /usr/share/cmake/Templates/CPack.GenericDescription.txt CPack Verbose: Remove toplevel directory: /path/to/build/_CPack_Packages/Linux/RPM CPack: Install projects CPack: - Run preinstall target for: madX CPack: - Install project: madX CPack Verbose: Install configuration: "Release" CPack Verbose: Installing: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux/usr/bin/madx_dev CPack Verbose: Installing: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux/usr/include/madX/fortran_wrappers.h CPack: Compress package CPack Verbose: Compress files to: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm CPack: Finalize package CPack Verbose: Copy final package: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm to /path/to/build/madX-4.01.45-Linux.rpm CPack Error: Problem copying the package: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm to /path/to/build/madX-4.01.45-Linux.rpm CPack Error: Error when generating package: madX ___ 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] Include-Dir order problem
On 02/13/2011 01:27 AM, Andreas Pakulat wrote: > Hi, > > I've got a somewhat tricky problem here with include directories. I'm > building a couple of source files and for some of them I need to add an > include-directory to the front of the list that cmake passes to the > compiler. At the same time other source files in that directory need to > not have that include-dir in front of the list. > > I can't see a way to do this, except by using COMPILE_FLAGS source file > properties for each and every file to specify include-dirs and not use > include_directories at all, as COMPILE_FLAGS always end up behind the > includes. > > So, am I missing something here? If not I guess I'll have to find that > bugreport about making include-dirs a source-file property and vote for > it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. 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
Re: [CMake] mixed compilation with two compilers
You should use ExternalProject, and possibly wrapper scripts to set
environment variables for the projects that need to use the different
compiler. (CC, CXX, FC env vars should be set during the configure stage, or
you can pass them in as -D args to cmake)
CMake does not support changing the compiler in a sub-portion of the build
tree.
On Tue, Feb 15, 2011 at 11:23 AM, Dominik Szczerba wrote:
> I need to compile a few subprojects (each is a subfolder with one
> library and a corresponding CMakeLists.txt) with the Intel compiler
> while the rest of the libraries (organized the same way), including
> the executable, using the system compiler (GNU on linux, VC on
> Windows). I tried two solutions to no avail:
>
> 1) In the subfolder's CMakeLists.txt do like:
>
>SET(CMAKE_CXX_COMPILER ${INTEL_CXX_COMPILER})
>SET(CMAKE_CXX_FLAGS_DEBUG ${INTEL_CXX_FLAGS_DEBUG})
>
> While this substitutes the CMAKE_CXX* variables correctly with
> INTEL_CXX* ones (confirmed by MESSAGE) the actual compilation still
> takes place using parent CMAKE_CXX_* variables. This is very
> surprising as many other CMake commands respect the subfolder scope.
>
> 2) Properties. There is a way to have ADDITIONAL compile flags, but
> not CUSTOM. There seems to be no property for the compiler itself.
>
> The compilation has to be mixed, and no post-processing (like some
> converting scripts) are allowed. Is this possible or this is a dead
> end?
>
> Best regards,
> Dominik
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] mixed compilation with two compilers
I need to compile a few subprojects (each is a subfolder with one
library and a corresponding CMakeLists.txt) with the Intel compiler
while the rest of the libraries (organized the same way), including
the executable, using the system compiler (GNU on linux, VC on
Windows). I tried two solutions to no avail:
1) In the subfolder's CMakeLists.txt do like:
SET(CMAKE_CXX_COMPILER ${INTEL_CXX_COMPILER})
SET(CMAKE_CXX_FLAGS_DEBUG ${INTEL_CXX_FLAGS_DEBUG})
While this substitutes the CMAKE_CXX* variables correctly with
INTEL_CXX* ones (confirmed by MESSAGE) the actual compilation still
takes place using parent CMAKE_CXX_* variables. This is very
surprising as many other CMake commands respect the subfolder scope.
2) Properties. There is a way to have ADDITIONAL compile flags, but
not CUSTOM. There seems to be no property for the compiler itself.
The compilation has to be mixed, and no post-processing (like some
converting scripts) are allowed. Is this possible or this is a dead
end?
Best regards,
Dominik
___
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] Setting target destination and rpath per generator
2011/2/15 David Cole : > You cannot do "cmake-ish" things in the CPACK_PROJECT_CONFIG_FILE. > > Neither install commands nor set_target_properties calls do anything in this > context. Yes you are right, but we may have expected that "CMAKE_INSTALL_RPATH" may be used at INSTALL time just like "CMAKE_INSTALL_DO_STRIP" or "CMAKE_INSTALL_PREFIX" are. That said, current status is one needs to build twice for fulfilling the Daryl's needs. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] detecting build configuration in Visual Studio
In MSVC I need to link different libraries depending on the chosen build type. I have two questions: 1) If and how can I register my own build types 2) How can I detect which one I am in for conditional linking Many thanks for any hints, Dominik ___ 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] Setting target destination and rpath per generator
You cannot do "cmake-ish" things in the CPACK_PROJECT_CONFIG_FILE.
Neither install commands nor set_target_properties calls do anything in this
context.
On Tue, Feb 15, 2011 at 9:36 AM, Daryl N wrote:
> Sorry, don't know how to reply inline with this editor. Yes,
> cpack_config.cmake is my CPACK_PROJECT_CONFIG_FILE. For rpath, here is what
> I have in the cpack config file:
>
> if (${CPACK_GENERATOR} STREQUAL "TGZ")
>
> set(CPACK_SET_DESTDIR OFF)
> set(CMAKE_INSTALL_RPATH ".")
> set_target_properties(npManager
> PROPERTIES INSTALL_RPATH ".")
> elseif (${CPACK_GENERATOR} STREQUAL "DEB")
> set(CPACK_SET_DESTDIR ON)
> set(CMAKE_INSTALL_RPATH "/usr/local/")
> set_target_properties(npManager
> PROPERTIES INSTALL_RPATH "/usr/local/ folder>")
> endif ()
>
> CMAKE_INSTALL_RPATH was initially set to /user/local/ in my
> main CMakeLists.txt file and it stays that way in TGZ even with the sets
> above. For the TGZ file I want to be able to unpack it and then just run it
> locally. If I use the bin/lib folder structure in the TGZ, then I would
> need to set rpath to "../lib" for them to be found. And then that would be
> part of the rpath for the DEB package too. Sounds like 2 build cycles may
> be needed.
>
> Daryl*
>
> From:* Eric Noulard
> *To:* Daryl N
> *Cc:* cmake@cmake.org
> *Sent:* Tue, February 15, 2011 4:00:17 AM
> *Subject:* Re: [CMake] Setting target destination and rpath per generator
>
> 2011/2/15 Daryl N :
> > Hi,
> >
> > I have a question on the use of CPack. I have CMake setup to generate
> > binaries and shared libraries. Up until now I have only created a TGZ
> with
> > rpath set to ".". This has worked nicely, but now I would like to create
> a
> > Debian package for proper installation. I have added DEB to
> CPACK_GENERATOR
> > and I've created my own cpack_config.cmake file. My goal is:
> >
> > 1. Run cmake/make package once and create the tar.gz file with all
> exe/libs
> > in the root folder of the tar.gz file with rpath set to ".".
> > 2. Create new .deb package with exes in /usr/local/bin and libs in
> > /usr/local/lib. Alternatively, since files are private, all could be put
> in
> > /usr/local/.
> >
> > I've attempted this by creating my own cpack_config.cmake file to try to
> > override some settings per generator. Some observations:
> >
> > 1. I've been unable to set the install( DESTINATION) path per
> > generator in my cpack_config.cmake file. Whatever the variable is set to
> > when the install(...) is processed in the CMakeLists.txt file is what is
> > used for all generators. Just want to confirm changing this isn't an
> option
> > per generator.
> >
> > The above has prevented me from having my install lines like:
> > install( DESTINATION ${BIN_PATH})
> > install( DESTINATION ${LIB_PATH})
> > and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
> > them to "." for TGZ, since I can't change the variable in
> > .
>
> I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
> As far as I know you cannot change install rules on "CPack generator
> basis".
>
> install rules belongs to CMakeLists.txt and they are evaluated at
> CMake-time
> (not CPack-time).
>
> cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
> You can do CPack-generator specific actions in this file.
> (like setting CPACK_SET_DESTDIR OFF or ON or changing
> CPACK_PACKAGING_INSTALL_PREFIX etc...)
>
> I did not tried playing with rpath but may be you can
>
> if(CPACK_GENERATOR MATCHES "TGZ")
> set(CMAKE_INSTALL_RPATH ".")
> set(CPACK_SET_DESTDIR "OFF")
> endif(CPACK_GENERATOR MATCHES "TGZ")
>
> if(CPACK_GENERATOR MATCHES "DEB")
> set(CPACK_PACKAGING_INSTALL_PREFIX "/usr/local/")
> endif(CPACK_GENERATOR MATCHES "DEB")
>
> > 2. I would also like to set the rpath per generator. So the targets in
> the
> > TGZ only look in "." while the DEB installed targets only look in
> > /usr/local/. But I haven't been able to update the rpath
> per
> > generator in cpack_config.cmake. I've tried both setting
> > CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
> > INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
>
> I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
> (as I suggested in my previous example) you'll have to try and
> may be verify in the CMake source code in order to check when it is
> handled.
> Whatever the current status,
> I don't see why it couldn't be handled at CPack time
> (but I may be missing something).
>
> >Do I need to run cpack
> > separately changing the variables before hand? I suppose that would mean
> 2
> > builds cycles also, once for each generator.
>
> 2 build cycles will definitely work.
>
> However if you gives us more information on what's inside your
> "cpack_config.cmake"
> what works what does not work with it, may be we can see if it it can
> be done in a single bu
Re: [CMake] Setting target destination and rpath per generator
Sorry, don't know how to reply inline with this editor. Yes,
cpack_config.cmake
is my CPACK_PROJECT_CONFIG_FILE. For rpath, here is what I have in the cpack
config file:
if (${CPACK_GENERATOR} STREQUAL "TGZ")
set(CPACK_SET_DESTDIR OFF)
set(CMAKE_INSTALL_RPATH ".")
set_target_properties(npManager
PROPERTIES INSTALL_RPATH ".")
elseif (${CPACK_GENERATOR} STREQUAL "DEB")
set(CPACK_SET_DESTDIR ON)
set(CMAKE_INSTALL_RPATH "/usr/local/")
set_target_properties(npManager
PROPERTIES INSTALL_RPATH "/usr/local/")
endif ()
CMAKE_INSTALL_RPATH was initially set to /user/local/ in my main
CMakeLists.txt file and it stays that way in TGZ even with the sets above. For
the TGZ file I want to be able to unpack it and then just run it locally. If I
use the bin/lib folder structure in the TGZ, then I would need to set rpath to
"../lib" for them to be found. And then that would be part of the rpath for
the
DEB package too. Sounds like 2 build cycles may be needed.
Daryl
From: Eric Noulard
To: Daryl N
Cc: cmake@cmake.org
Sent: Tue, February 15, 2011 4:00:17 AM
Subject: Re: [CMake] Setting target destination and rpath per generator
2011/2/15 Daryl N :
> Hi,
>
> I have a question on the use of CPack. I have CMake setup to generate
> binaries and shared libraries. Up until now I have only created a TGZ with
> rpath set to ".". This has worked nicely, but now I would like to create a
> Debian package for proper installation. I have added DEB to CPACK_GENERATOR
> and I've created my own cpack_config.cmake file. My goal is:
>
> 1. Run cmake/make package once and create the tar.gz file with all exe/libs
> in the root folder of the tar.gz file with rpath set to ".".
> 2. Create new .deb package with exes in /usr/local/bin and libs in
> /usr/local/lib. Alternatively, since files are private, all could be put in
> /usr/local/.
>
> I've attempted this by creating my own cpack_config.cmake file to try to
> override some settings per generator. Some observations:
>
> 1. I've been unable to set the install( DESTINATION) path per
> generator in my cpack_config.cmake file. Whatever the variable is set to
> when the install(...) is processed in the CMakeLists.txt file is what is
> used for all generators. Just want to confirm changing this isn't an option
> per generator.
>
> The above has prevented me from having my install lines like:
> install( DESTINATION ${BIN_PATH})
> install( DESTINATION ${LIB_PATH})
> and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
> them to "." for TGZ, since I can't change the variable in
> .
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on "CPack generator basis".
install rules belongs to CMakeLists.txt and they are evaluated at CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES "TGZ")
set(CMAKE_INSTALL_RPATH ".")
set(CPACK_SET_DESTDIR "OFF")
endif(CPACK_GENERATOR MATCHES "TGZ")
if(CPACK_GENERATOR MATCHES "DEB")
set(CPACK_PACKAGING_INSTALL_PREFIX "/usr/local/")
endif(CPACK_GENERATOR MATCHES "DEB")
> 2. I would also like to set the rpath per generator. So the targets in the
> TGZ only look in "." while the DEB installed targets only look in
> /usr/local/. But I haven't been able to update the rpath per
> generator in cpack_config.cmake. I've tried both setting
> CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
> INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
>Do I need to run cpack
> separately changing the variables before hand? I suppose that would mean 2
> builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
"cpack_config.cmake"
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue is the fact that as far as I understand your
need you want
to put all files (libs, exe) in a single folder for the TGZ and have
prefix+/lib, prefix+/bin
in the DEB case?
Changing the prefix is easy but adding (or removing) the extra /lib
and /bin I don't
currently know how to do that. Why won't you keep the lib and bin
suffix in the TGZ case?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel
Re: [CMake] FIND_PATH issue in FindQt4.cmake
Hi All,
Thanks for the help so far, I will check and see if CMake 2.8.4rc has the
same issue meanwhile I noticed that FIND_PATH seems to have special
instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on
page http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path
The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults to
"FIRST" on Darwin systems which I can interpret one of two ways.
First, If a standard library and a framework are found in the same search
order then CMAKE will use this variable to determine which to pick first.
Second, if a framework is found regardless of where it is in the search
order it will be picked. I suspect the choice is the first one. However, in
my test I found that if I set CMAKE_FIND_FRAMEWORK to be "LAST" then CMAKE
picks the proper path. This would make me think the second option is at play
or it is just pure coincidence that this option happened to give me the
correct result.
Any of you know what the correct option is? To me it would make sense that
FIND_PATH honors the search order which would mean that the HINTS option in
FindQt4 should have higher precedence than the Framework in the
CMAKE_SYSTEM_FRAMEWORK_PATH.
Thanks,
Hari
On Mon, Feb 14, 2011 at 11:54 PM, Andreas Pakulat wrote:
> On 14.02.11 16:18:09, Clinton Stimpson wrote:
> > On Monday, February 14, 2011 03:27:11 pm Harinarayan Krishnan wrote:
> > > Hi All,
> > >
> > > I was trying to build the VisIt software package on my Mac OSX 1.5 .
> This
> > > package uses Qt 4.6.1 during its build. I ran into an issue where the
> > > QtCore path finds my globally installed version of Qt (4.7) as apposed
> to
> > > the Qt (4.6.1).
> > >
> > > While digging around I found that FIND_PATH (code included below) in
> > > FindQt4.cmake is pulling information from the system path and assigning
> > > this value to the QT_QTCORE_INCLUDE_DIR. This is causing a build
> failure
> > > where the rest of the QT headers are using 4.6.1 and QtCore is using
> > > version 4.7.
> > >
> > > The value in ${qt_headers} points to the correct 4.6.1 location yet
> > > FIND_PATH does not use this parameter. Any ideas?
> > >
> > >
> > > _qt4_query_qmake(QT_INSTALL_HEADERS qt_headers)
> > > SET(QT_QTCORE_INCLUDE_DIR NOTFOUND)
> > > FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
> > >HINTS ${qt_headers}
> > >${QT_LIBRARY_DIR}/QtCore.framework/Headers
> > >PATH_SUFFIXES QtCore
> > >)
> > >
> >
> > Ok, I'm able to reproduce this problem.
> > I did notice that if I add the NO_CMAKE_SYSTEM_PATH option, then the
> problem
> > goes away. But, I thought HINTS had a higher priority than paths from
> the
> > Mac's platform files.
> > And, I don't see this problem on Linux.
> > Is this a bug in find_path() ??
>
> Definetly, the only thing that has higher priority than HINTS are values
> from the cmake or environment variables CMAKE_PREFIX_PATH,
> CMAKE_INCLUDE_PATH and CMAKE_FRAMEWORK_PATH. There's no special
> behaviour for MacOSX documented.
>
> Someone should file a bugreport after verifying this still happens with
> the latest rc of 2.8.4.
>
> Andreas
>
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
> >
>
> --
> The time is right to make new friends.
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Error: Cannot determine link language for target
Show us your code. On Tue, Feb 15, 2011 at 8:08 AM, Kiran Gopal Patil wrote: > Hi , > > I do get this error while build a application using CMAKE. > Please help me in resolving this one. > I tried to use the SET_TARGET_PROPERTIES but not successful. > > I do have mix of C and C++ static libs in my project. > > -- > Thanks & Regards, > Kiran Patil > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake Error: Cannot determine link language for target
Hi , I do get this error while build a application using CMAKE. Please help me in resolving this one. I tried to use the SET_TARGET_PROPERTIES but not successful. I do have mix of C and C++ static libs in my project. -- Thanks & Regards, Kiran Patil ___ 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] Global STATIC_LIBRARY_FLAGS_ ?
Hi guys, Any plans to add a CMAKE_STATIC_LIBRARY_FLAGS_ ? It seems rather weird that I can set 'global' linking flags as well as compilation flags, but that the static_library step flags are tied to a target. I know this can all be 'hacked' with overriding the add_library() call, but it's not very pretty. Anyone? Thanks /Johan ___ 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_STRIP_FILES has no effect on DSOs
On 02/11/2011 11:38 AM, Eric Noulard wrote: > So you may perfectly have shared lib in your build tree which are not stripped > and get them stripped in the package. Ha! I did not check that; i.e. we alway run 'make install' before 'make package' and I presumed that install location was where the stripped binaries were to be found. That makes a lot of sense now. So bottom line: it works and I rattled the cages for nothing. Cheers and sorry about the noise, .mm ___ 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] Setting target destination and rpath per generator
2011/2/15 Daryl N :
> Hi,
>
> I have a question on the use of CPack. I have CMake setup to generate
> binaries and shared libraries. Up until now I have only created a TGZ with
> rpath set to ".". This has worked nicely, but now I would like to create a
> Debian package for proper installation. I have added DEB to CPACK_GENERATOR
> and I've created my own cpack_config.cmake file. My goal is:
>
> 1. Run cmake/make package once and create the tar.gz file with all exe/libs
> in the root folder of the tar.gz file with rpath set to ".".
> 2. Create new .deb package with exes in /usr/local/bin and libs in
> /usr/local/lib. Alternatively, since files are private, all could be put in
> /usr/local/.
>
> I've attempted this by creating my own cpack_config.cmake file to try to
> override some settings per generator. Some observations:
>
> 1. I've been unable to set the install( DESTINATION) path per
> generator in my cpack_config.cmake file. Whatever the variable is set to
> when the install(...) is processed in the CMakeLists.txt file is what is
> used for all generators. Just want to confirm changing this isn't an option
> per generator.
>
> The above has prevented me from having my install lines like:
> install( DESTINATION ${BIN_PATH})
> install( DESTINATION ${LIB_PATH})
> and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
> them to "." for TGZ, since I can't change the variable in
> .
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on "CPack generator basis".
install rules belongs to CMakeLists.txt and they are evaluated at CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES "TGZ")
set(CMAKE_INSTALL_RPATH ".")
set(CPACK_SET_DESTDIR "OFF")
endif(CPACK_GENERATOR MATCHES "TGZ")
if(CPACK_GENERATOR MATCHES "DEB")
set(CPACK_PACKAGING_INSTALL_PREFIX "/usr/local/")
endif(CPACK_GENERATOR MATCHES "DEB")
> 2. I would also like to set the rpath per generator. So the targets in the
> TGZ only look in "." while the DEB installed targets only look in
> /usr/local/. But I haven't been able to update the rpath per
> generator in cpack_config.cmake. I've tried both setting
> CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
> INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
>Do I need to run cpack
> separately changing the variables before hand? I suppose that would mean 2
> builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
"cpack_config.cmake"
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue is the fact that as far as I understand your
need you want
to put all files (libs, exe) in a single folder for the TGZ and have
prefix+/lib, prefix+/bin
in the DEB case?
Changing the prefix is easy but adding (or removing) the extra /lib
and /bin I don't
currently know how to do that. Why won't you keep the lib and bin
suffix in the TGZ case?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
