Re: [CMake] Generated source file dependencies
The problem is that when using visual studio, A might be built before B, and fails to build because B.h has not yet be generated. Did you try ADD_DEPENDENCIES(A B) ? I have TARGET_LINK_LIBRARIES(A B), so I think the library dependency is correctly handled. But there is still no dependency to B.h. TARGET_LINK_LIBRARIES are link-time dependencies ADD_DEPENDENCIES are something must be built before something # From the manual: Adding dependencies with ADD_DEPENDENCIES can be used to make sure one target is built before another target. # TARGET_LINK_LIBRARIES: Specify a list of libraries to be linked into the specified target. ___ 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] Generated source file dependencies
Denis Scherbakov a écrit : The problem is that when using visual studio, A might be built before B, and fails to build because B.h has not yet be generated. Did you try ADD_DEPENDENCIES(A B) ? I have TARGET_LINK_LIBRARIES(A B), so I think the library dependency is correctly handled. But there is still no dependency to B.h. TARGET_LINK_LIBRARIES are link-time dependencies ADD_DEPENDENCIES are something must be built before something # From the manual: Adding dependencies with ADD_DEPENDENCIES can be used to make sure one target is built before another target. # TARGET_LINK_LIBRARIES: Specify a list of libraries to be linked into the specified target. Well at first glance it seemed to work, but in fact it is not : A is still built before B, and fails to build missing B.h. Please note that this only occurs on visual studio. Julien -- Julien MICHEL - Ingénieur d'études - Traitement d'images CS Systèmes d'Information - Division ESPACE Département Information Géographique Image Téléphone : +33 561 17 64 27 Email : julien.mic...@c-s.fr ___ 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] Generated source file dependencies
Well at first glance it seemed to work, but in fact it is not : A is still built before B, and fails to build missing B.h. Please note that this only occurs on visual studio. Try to set B.h source file properties as GENERATED and include it into A_SRCS. Maybe this help. Could you provide your CMakeLists.txt? ___ 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] Generated source file dependencies
Denis Scherbakov a écrit : Well at first glance it seemed to work, but in fact it is not : A is still built before B, and fails to build missing B.h. Please note that this only occurs on visual studio. Try to set B.h source file properties as GENERATED and include it into A_SRCS. Maybe this help. Could you provide your CMakeLists.txt? My mistake, it seems to be fixed with the first proposed solution. No idea why it did not work at first. Thanks a lot for your help, Best Regards, Juline Michel -- Julien MICHEL - Ingénieur d'études - Traitement d'images CS Systèmes d'Information - Division ESPACE Département Information Géographique Image Téléphone : +33 561 17 64 27 Email : julien.mic...@c-s.fr ___ 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] include_directories per target
Olivier Delannoy olivier.delan...@gmail.com wrote: I would like to set include_directories on a per target basis. I understand that the INCLUDE_DIRECTORIES property is currently on a per folder basis. It is a bit of a problem as I would like to flatten my build and have all my targets generated in a single destination folder. Is there any way to achieve this currently? The per folder basis refers to the source directories or folders. You don't need to flatten the entire source of your project in order to put the built libraries and executables in one directory. Instead, direct the output of each target to the common directory. For example, I have a project under CMake that puts all the executable code in files in one directory, but the source for each target is in a directory completely separate from any other target's source directory. (We don't even allow one target's source to be in a subdirectory of another target.) This seems to me to be a sensible way to organize such a project even if you were not using CMake. David A. Karr ___ 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_directories per target
On Wed, May 13, 2009 at 8:50 AM, david.k...@l-3com.com wrote: Olivier Delannoy olivier.delan...@gmail.com wrote: I would like to set include_directories on a per target basis. I understand that the INCLUDE_DIRECTORIES property is currently on a per folder basis. It is a bit of a problem as I would like to flatten my build and have all my targets generated in a single destination folder. Is there any way to achieve this currently? The per folder basis refers to the source directories or folders. You don't need to flatten the entire source of your project in order to put the built libraries and executables in one directory. Instead, direct the output of each target to the common directory. That would be my suggestion as I have spent a lot of time taking flat src structures and making folders so I can organize my code.. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] include_directories per target
I have probably wrongly explained my issue. I have my source code located in several folders based on the component / library they are part of. But I don't want to have recursive make so I don't want to have my project relying on add_subdirectory(). Thus all my target are located in the main directory and refers to file located in different folders relative to the current hierarchy. I don't think there is anything wrong with that and I know how to do it. However, I would like to be able to ensure that only the library/component that use a library have access to the header file of that library. On Wed, May 13, 2009 at 2:03 PM, John Drescher dresche...@gmail.com wrote: On Wed, May 13, 2009 at 8:50 AM, david.k...@l-3com.com wrote: Olivier Delannoy olivier.delan...@gmail.com wrote: I would like to set include_directories on a per target basis. I understand that the INCLUDE_DIRECTORIES property is currently on a per folder basis. It is a bit of a problem as I would like to flatten my build and have all my targets generated in a single destination folder. Is there any way to achieve this currently? The per folder basis refers to the source directories or folders. You don't need to flatten the entire source of your project in order to put the built libraries and executables in one directory. Instead, direct the output of each target to the common directory. That would be my suggestion as I have spent a lot of time taking flat src structures and making folders so I can organize my code.. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Olivier Delannoy Website: http://olivier.delannoy.dalfy.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] include_directories per target
Olivier Delannoy wrote: I have probably wrongly explained my issue. I have my source code located in several folders based on the component / library they are part of. But I don't want to have recursive make so I don't want to have my project relying on add_subdirectory(). Thus all my target are located in the main directory and refers to file located in different folders relative to the current hierarchy. I don't think there is anything wrong with that and I know how to do it. However, I would like to be able to ensure that only the library/component that use a library have access to the header file of that library. Why are you afraid of recursive make? CMake does not generate makefiles like that anyway. It does use some recursive make, but will use that regardless of add_subdirectory or not. It is needed to get depend information to work correctly, and to make sure everything is up-to-date and in place before the build. CMake will do the right thing if you use add_subdirectory. -Bill ___ 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] Check if variable is already is cache
Hi all, I vaguely remember I read on this mailing list that it is possible to check whether a variable is already in cache. Something like this: if(CACHED var) ... endif(CACHED var) However, I cannot find anything about this in the manual. Is it possible, or does my memory serve me bad? Best regards, Marcel Loose. ___ 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 - Beta or Alpha version?
Hi, I was looking at the list of CPack variables. There are variables to set the major, minor, and patch version numbers. But isn't there anything to set a beta or alpha number? For instance, what if I wanted a 1.0B1 version? Thanks, Brandon -- www.perpetualseeker.com Blog about college, programming, and other random things. Follow me on Twitter: http://twitter.com/devbanana ___ 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 - Beta or Alpha version?
2009/5/13 Brandon Olivares programmer2...@gmail.com:
Hi,
I was looking at the list of CPack variables. There are variables to set the
major, minor, and patch version numbers. But isn't there anything to set a
beta or alpha number?
For instance, what if I wanted a 1.0B1 version?
SET(CPACK_PACKAGE_VERSION_MAJOR 1)
SET(CPACK_PACKAGE_VERSION_MINOR 0B1)
SET(CPACK_PACKAGE_VERSION_PATCH )
Those 3 are used to build the CPACK_PACKAGE_VERSION
thus you may overwrite the CPACK_PACKAGE_VERSION alltogether with
SET(CPACK_PACKAGE_VERSION 1.0B1).
The CPACK_PACKAGE_VERSION is defined by CPack iff it is not already defined:
from CPack.cmake:
cpack_set_if_not_set(CPACK_PACKAGE_VERSION
${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH})
--
Erk
___
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] Check if variable is already is cache
On Wednesday 13 May 2009, Marcel Loose wrote: Hi all, I vaguely remember I read on this mailing list that it is possible to check whether a variable is already in cache. Something like this: if(CACHED var) ... endif(CACHED var) However, I cannot find anything about this in the manual. Is it possible, or does my memory serve me bad? In doubt, check the sources: http://public.kitware.com/cgi-bin/viewcvs.cgi/Source/cmIfCommand.cxx?root=CMakeview=markup Doesn't seem so. 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] Static linking and find_library
On Mon, May 11, 2009 at 1:39 PM, Brad King brad.k...@kitware.com wrote: Bill Hoffman wrote: Marcel Loose wrote: 2) How can I persuade find_library() to only search for static libraries? You can't. Yes, you can: find_library(MATH_LIB NAMES libm.a) If you specify a valid library name then CMake will look for it directly instead of prepending 'lib' and appending library extensions. The reason there is no generic find a static library option is because it is almost impossible to implement on windows where one cannot distinguish import libraries and static libraries by their name. Based on my experience, the necessity to enforce static links is almost always a platform specific issue (cf. computing clusters). And therefore, dare I say, CMakeLists.txt is not the place to enforce this, and certainly having to input platform specific stuff in my CMakeLists.txt is quite tiresome to say the least. (moreover, in such setting, the complication with windows and friends is irrelevant). So, if I may, let me shift the question a little bit: How can one enforce static linkage on a per platform basis (not the whole project)? In other words, what setting can we insert into a toolchain filehttp://www.vtk.org/Wiki/CMake_Cross_Compilingto make this possible? Let me identify a problem here with find_library(). Here is a repeatable scenario; take the following 3 line CMakeLists.txt: project( foo CXX ) cmake_minimum_required(VERSION 2.6) find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH ) where somewhere in the list LD_LIBRARY_PATH there exists libfoo.so and libfoo.a (replace foo with an actual lib in your environment). Then with CMake 2.6.x or today's HEAD version, run cmake in the following 4 different ways: 1. cmake .. 2. cmake -DCMAKE_SYSTEM_NAME=Generic .. 3. cmake -DCMAKE_SYSTEM_NAME=Catamount .. 4. cmake -DCMAKE_TOOLCHAIN_FILE=sysbar.cmake .. Case (1) will yield libfoo.so, case (2) will yield libfoo.so, and case (3) will yield libfoo.a. Case (4) uses a custom crafted toolchain file, let's leave that for later. Confusion grows deeper once one digs into the Platform files.. Take the line (and the only line) in share/cmake-2.x/Modules/Platform/Generic.cmake: SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) and it seems to have no effect. [..]Platform/Catamount.cmake also has this line along with bunch of other stuff, and it successfully forces find_library() to get to the static library. In Case(4) the custom toolchain file sysbar.cmake is nothing but set(CMAKE_SYSTEM_NAME Generic) followed by the rest of the stuff in Catamount.cmake. Case(4), quite confusingly, finds libfoo.so!! Sorry for the long message, but I really tried to condense it as much as I could. Any ideas? - Levent ___ 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] Static linking and find_library
S. Levent Yilmaz wrote:
How can one enforce static linkage on a per platform basis (not the whole project)?
In other words, what setting can we insert into a toolchain file
http://www.vtk.org/Wiki/CMake_Cross_Compiling to make this possible?
Let me identify a problem here with find_library(). Here is a repeatable
scenario; take the following 3 line CMakeLists.txt:
project( foo CXX )
cmake_minimum_required(VERSION 2.6)
find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH )
^^^
This is almost certainly a bad idea. The find_library command already
provides lots of customization features. See its documentation.
Also, if you're trying to build static libs then why search in dynamic
loader paths for libraries?
What happens in your cases when it is not done?
2. cmake -DCMAKE_SYSTEM_NAME=Generic ..
3. cmake -DCMAKE_SYSTEM_NAME=Catamount ..
I don't think direct definition of CMAKE_SYSTEM_NAME is supported.
It's supposed to be detected and set by the platform files. Only
through a toolchain file should it be customized. (Alex?)
line (and the only line) in share/cmake-2.x/Modules/Platform/Generic.cmake:
SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
It's mostly for reference by CMakeLists.txt code in the project.
and it seems to have no effect. [..]Platform/Catamount.cmake also has
this line along with bunch of other stuff, and it successfully forces
find_library() to get to the static library. In Case(4) the custom
toolchain file sysbar.cmake is nothing but set(CMAKE_SYSTEM_NAME
Generic) followed by the rest of the stuff in Catamount.cmake. Case(4),
quite confusingly, finds libfoo.so!!
Your file sets CMAKE_FIND_LIBRARY_SUFFIXES but CMake loads the module
CMakeGenericSystem.cmake *after* the toolchain file and changes it back
to putting .so in the list. The toolchain file is just supposed to
specify some very basic information which triggers loading of platform-
specific configuration.
The documentation you reference at
http://www.cmake.org/Wiki/CMake_Cross_Compiling
says that a ${CMAKE_SYSTEM_NAME}.cmake module is mandatory.
The module will be loaded after CMakeGenericSystem.cmake so it gets
the final say in values of variables like CMAKE_FIND_LIBRARY_SUFFIXES.
This is why it works for Catamount. You need to create a module like
Catamount.cmake for your own target platform, and put it somewhere
referenced by CMAKE_MODULE_PATH (Alex, can you confirm this?).
-Brad
___
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] Static linking and find_library
On Wednesday 13 May 2009, Brad King wrote:
S. Levent Yilmaz wrote:
How can one enforce static linkage on a per platform basis (not the whole
project)? In other words, what setting can we insert into a toolchain
file http://www.vtk.org/Wiki/CMake_Cross_Compiling to make this
possible?
Let me identify a problem here with find_library(). Here is a repeatable
scenario; take the following 3 line CMakeLists.txt:
project( foo CXX )
cmake_minimum_required(VERSION 2.6)
find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH )
^^^
This is almost certainly a bad idea. The find_library command already
provides lots of customization features. See its documentation.
Also, if you're trying to build static libs then why search in dynamic
loader paths for libraries?
What happens in your cases when it is not done?
2. cmake -DCMAKE_SYSTEM_NAME=Generic ..
3. cmake -DCMAKE_SYSTEM_NAME=Catamount ..
I don't think direct definition of CMAKE_SYSTEM_NAME is supported.
It's supposed to be detected and set by the platform files. Only
through a toolchain file should it be customized. (Alex?)
Well, after all, it's just a cmake variable, so it can also be set from the
command line.
If it is already set when cmake would try to determine the system, it
interprets this as cross compiling, i.e. CMAKE_SYSTEM is already set because
the system you want to build for is not the current host system, but a
different one, and that's why (and only that's why) it should be set.
line (and the only line) in
share/cmake-2.x/Modules/Platform/Generic.cmake:
SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
It's mostly for reference by CMakeLists.txt code in the project.
This disables the building of shared libraries and produces warnings
for add_library(SHARED).
and it seems to have no effect. [..]Platform/Catamount.cmake also has
this line along with bunch of other stuff, and it successfully forces
find_library() to get to the static library. In Case(4) the custom
toolchain file sysbar.cmake is nothing but set(CMAKE_SYSTEM_NAME
Generic) followed by the rest of the stuff in Catamount.cmake. Case(4),
quite confusingly, finds libfoo.so!!
Your file sets CMAKE_FIND_LIBRARY_SUFFIXES but CMake loads the module
CMakeGenericSystem.cmake *after* the toolchain file and changes it back
to putting .so in the list. The toolchain file is just supposed to
specify some very basic information which triggers loading of platform-
specific configuration.
Yes.
It should only preset the things cmake can not automatically detect when cross
compiling, i.e. the target system name, where the target environment is
located, and which compiler to use.
The documentation you reference at
http://www.cmake.org/Wiki/CMake_Cross_Compiling
says that a ${CMAKE_SYSTEM_NAME}.cmake module is mandatory.
The module will be loaded after CMakeGenericSystem.cmake so it gets
the final say in values of variables like CMAKE_FIND_LIBRARY_SUFFIXES.
This is why it works for Catamount. You need to create a module like
Catamount.cmake for your own target platform, and put it somewhere
referenced by CMAKE_MODULE_PATH (Alex, can you confirm this?).
Yes.
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] Static linking and find_library
On Wed, May 13, 2009 at 4:09 PM, Brad King brad.k...@kitware.com wrote: S. Levent Yilmaz wrote: How can one enforce static linkage on a per platform basis (not the whole project)? In other words, what setting can we insert into a toolchain file http://www.vtk.org/Wiki/CMake_Cross_Compiling to make this possible? Let me identify a problem here with find_library(). Here is a repeatable scenario; take the following 3 line CMakeLists.txt: project( foo CXX ) cmake_minimum_required(VERSION 2.6) find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH ) ^^^ This is almost certainly a bad idea. The find_library command already provides lots of customization features. Seeits documentation. Don't get hang up on this, it is just an example (although I'd really love to hear you describe why it is a bad idea, and pls dont' rtfm me -- no rhetoric intended). That said, a simple find_library( FOO_LIBRARY foo ) won't find libfoo.a since libfoo is not at some standard location, as is usually the case with cross compiling; that is, unless one sets a proper CMAKE_FIND_ROOT_PATH for a given system.. and we're back to this being a simple example.. (And yes, I was referring to cross compiling scenarios throughout; sorry if that wasn't clear enough in my post). Also, if you're trying to build static libs then why search in dynamic loader paths for libraries? Because static libs are usually under the same directory as dynamic libs. And dynamic libs ARE installed by the administrator, even though users aren't supposed to use them. I can dwell more on this point, but rather not. Let's just say these are the kind of systems I have to deal with.. Your file sets CMAKE_FIND_LIBRARY_SUFFIXES but CMake loads the module CMakeGenericSystem.cmake *after* the toolchain file and changes it back to putting .so in the list. The toolchain file is just supposed to specify some very basic information which triggers loading of platform- specific configuration. I see. that's good to know. looking back at the wiki on cross compiling, this info is indeed there. I just didn't realize the CMakeGenericSystem.cmake is part of the distribution already.. anyways. -- Levent ___ 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] Static linking and find_library
I don't think direct definition of CMAKE_SYSTEM_NAME is supported.
It's supposed to be detected and set by the platform files. Only
through a toolchain file should it be customized. (Alex?)
Well, after all, it's just a cmake variable, so it can also be set from the
command line.
Quoting http://www.vtk.org/Wiki/CMake_Cross_Compiling
-- The toolchain file --
Defining all the variables mentioned above using -DCMAKE_SYSTEM_NAME etc.
would be quite tedious and error prone. To make things easier, there is
another cmake variable you can set:
so, it just convenience (and good design) to put these in a file, right?
[..] The toolchain file is just supposed to
specify some very basic information which triggers loading of platform-
specific configuration.
Yes.
It should only preset the things cmake can not automatically detect when
cross
compiling, i.e. the target system name, where the target environment is
located, and which compiler to use.
Can I argue that the need to build a statically linked executable is also a
cross compiling issue? If yes, then toolchain file should also be able to
set this..
The documentation you reference at
http://www.cmake.org/Wiki/CMake_Cross_Compiling
says that a ${CMAKE_SYSTEM_NAME}.cmake module is mandatory.
The module will be loaded after CMakeGenericSystem.cmake so it gets
the final say in values of variables like CMAKE_FIND_LIBRARY_SUFFIXES.
This is why it works for Catamount. You need to create a module like
Catamount.cmake for your own target platform, and put it somewhere
referenced by CMAKE_MODULE_PATH (Alex, can you confirm this?).
Yes.
Alex
So, to sum it up, is our only option to force find_library() to seek out
static libs is to create a Platform module?
- Levent
___
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
