Re: [CMake] find_package with ###Config.cmake
Am Freitag, den 03.12.2010, 08:45 +0100 schrieb Andreas Pakulat:
On 03.12.10 07:11:23, Micha Renner wrote:
There is a small library TLib which is installed like this
Install the project...
-- Install configuration: Debug
-- Installing: /usr/local/lib/libTLibd.so
-- Installing: /usr/local/lib/TLib/TLibExport.cmake
-- Installing: /usr/local/lib/TLib/TLibExport-debug.cmake
-- Installing: /usr/local/include/TLib/cmFile.h
-- Installing: /usr/local/lib/TLib/TLIBConfig.cmake
-- Installing: /usr/local/lib/TLib/TLIBConfigVersion.cmake
The CMakeLists file for the application program has the following line
to find the library
FIND_PACKAGE(TLIB)
This works, surprisingly, very good. No CMAKE_MODULE_PATH, no TLIB_DIR
in this case.
But...
If I call FIND_PACKAGE with version:
FIND_PACKAGE(TLIB 1.3)
I get the std-warning:
-
CMake Warning at TestDLL/CMakeLists.txt:20 (FIND_PACKAGE):
Could not find module FindTLIB.cmake or a configuration file for
package
TLIB.
Adjust CMAKE_MODULE_PATH or TLIB_DIR...
-
Why can't CMake find the TLIBConfig file, if FIND_PACKAGE is called with
version and TLIB_DIR is not set?
The problem might not be finding the Config file, but rather that the
ConfigVersion file doesn't set the VERSION_COMPATIBLE or VERSION_EXACT
variables. Or maybe it even sets the VERSION_UNSUITABLE to indicate that
the installed version of TLib doesn't match the version you request.
Unfortunately cmake currently cannot seem to distinguish between these
two cases (non-matching version vs. no config-file found), hence it
produces the same message in both cases.
This was my first impression, so I used the ConfigVersion file of
http://www.cmake.org/Wiki/CMake_2.6_Notes to be on the safe side.
SET(PACKAGE_NAME TLib)
SET(PACKAGE_VERSION 1.3)
IF(${PACKAGE_FIND_VERSION_MAJOR} EQUAL 1)
SET(PACKAGE_VERSION_COMPATIBLE 1)
IF(${PACKAGE_FIND_VERSION_MINOR} EQUAL 3)
SET(PACKAGE_VERSION_EXACT 1)# exact match for version 1.3
ENDIF(${PACKAGE_FIND_VERSION_MINOR} EQUAL 3)
ENDIF(${PACKAGE_FIND_VERSION_MAJOR} EQUAL 1)
But this also does not work.
Greetings
Micha
___
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] Linking archives in a sibling directory
On 12/02/2010 03:13 PM, Raymond Wan wrote:
Hi Michael,
On Thu, Dec 2, 2010 at 19:40, Michael Hertling mhertl...@online.de wrote:
On 12/01/2010 06:03 PM, Raymond Wan wrote:
Ah! I see. Then is it recommended that this top-level CMakeLists.txt
have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
here as well? Or is this really up to me and there isn't a
suggested paradigm?
Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
placed in the same directory as the related source files unless there's
a reason not to do so; this makes for modularity and a well organized
code base. The above-mentioned directory structure with its top-level
CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
modules main, dir-A and dir-B separate with minimal interconnections.
In the previous structure, e.g., main/CMakeLists.txt had to know that
dir-A resides in ../dir-A; now, such information is concentrated in
the top-level CMakeLists.txt, and the sole reference of main to dir-A
is the target subprogA_ar. Due to CMake's capabilities to track the
dependencies among targets, it doesn't matter where dir-A is placed
within the project's source tree. So, in short, don't move the
ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.
I see -- I did not realize this point you made about CMake's
dependency tracking abilities. So, basically the only thing I need to
worry about is the order of the ADD_SUBDIRECTORY ()'s. As long as I
put
ADD_SUBDIRECTORY (dir-A)
before
ADD_SUBDIRECTORY (main)
then main will be built correctly?
Even this is not necessary if the only reference of main to dir-A is
TARGET_LINK_LIBRARIES(... subprogA_ar) in main/CMakeLists.txt since
TARGET_LINK_LIBARIES(), AFAIK, does a lazy evaluation of the targets'
dependencies, i.e. they are evaluated when all CMakeLists.txt files
have been processed and, hence, all dependencies are known. If you
refer to subprogA_ar in another way, e.g. SET_TARGET_PROPERTIES(),
then you will get an error if dir-A hasn't been configured yet.
But, if I am not mistaken and following what you are saying, I can
only build main using the top-level CMakeLists.txt. The lower
CMakeLists.txt in main/ does not know the location of dir-A. The
only way for both to work is to have this in main/CMakeLists.txt:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
yet this kind of duplication should be an error at worse; unnecessary
repetition at best?
Each invocation of ADD_SUBDIRECTORY() for a source directory must be
associated with an own binary directory, so the above-mentioned line
would allow you to use both alternatives. However, when configuring
the top-level CMakeLists.txt, you will get an error due to multiple
definitions of the subprogA_ar target. In main/CMakeLists.txt, you
might protect ADD_SUBDIRECTORY() against multiple invocations like
IF(NOT TARGET subprogA_ar)
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
or
IF(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
but this does not appear really appropriate to me.
Nevertheless, I wonder why you want to build main by configuring its
own source directory and alternatively via the top-level directory. If
this is because you'd like to exclude some modules from building, you
should handle such things in the top-level CMakeLists.txt, e.g. like:
# Define options:
OPTION(WITH_MAIN Build module main ON)
OPTION(WITH_A Build module A ON)
OPTION(WITH_B Build module B ON)
# Handle dependencies:
IF(WITH_MAIN)
SET(WITH_A ON)
ENDIF()
# Enable modules:
IF(WITH_B)
ADD_SUBDIRECTORY(dir-B)
ENDIF()
IF(WITH_A)
ADD_SUBDIRECTORY(dir-A)
ENDIF()
IF(WITH_MAIN)
ADD_SUBDIRECTORY(main)
ENDIF()
So, you can conveniently enable/disable the modules on the command line
or in the GUI, e.g. with cmake -DWITH_B=OFF path/to/top-level-dir
if you don't want to build module B.
As an alternative, you might consider to move dir-A to main/dir-A if
dir-A is essentially a submodule of main, but referring to a sibling
dir-A from main indicates that the latter is not sufficiently self-
contained to be built on its own with a cmake path/to/main, so
the modules' relationships should be handled by other means, IMO.
Regards,
Michael
The top-level directory of non-trivial projects should not contain any
source files, perhaps a config.h header or the like. Usually, there're
enough things gathering in a project's root, e.g. READMEs, subdirs for
documentation, resources or CMake stuff, a CMakeLists.txt file ;) etc.
The sources, however, should be organized in their own subdirectories,
so the top-level CMakeLists.txt typically contains ADD_SUBDIRECTORY()
commands along with configurational stuff like setting up compiler
flags, processing options or investigating the underlying system,
but no ADD_EXECUTABLE() or the like.
Of course,
Re: [CMake] Need some directions for non-trivial setup
On 2-12-2010 at 16:12, in message aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.com, Klaim mjkl...@gmail.com wrote: Hi! I'm currently trying to understand how to use CMake for a non-trivial setup of multiple-projects-framework. I'm a beginner at CMake (as developer I mean, not as library user). I've read the docs and I tried to read the Ogre project CMake organization but it's a bit overkill for my project I think. Anyway, I'm lost here because I think I don't understand all I need to achieve what I want. My project is made of several sub projects that are all in separate (mercurial) repositories. There is one default repository that use the mercurial subrepos feature to gather everything in one big framework project. You can see the repos there : http://code.google.com/p/art-of-sequence/source/browse/ (it's an open source project but Idon't have the website ready yet to explain the concept) The Cmake organisation I want to setup I've already seen somewhere else I think, but I'm a bit lost with all the ways to do it and I think I'll make something very bad if I don't ask here for help here. I need each project (subrepo) to be available separately and can be built giving to Cmake the paths of the project's dependencies. And I need the default repo to provide the paths. So I have this folder organisation in the default repo (that gather all subrepos) : /language # the intermediate language (AOSL) definition project/subrepo /tools/# the folder that will contain all the tools projects/subrepos /tools/aosdesigner # a tool project/subrepo (in fact the most important) - an executable /tools/aoslcpp # a tool project/subrepo that is a dependency of aosdesigner - a library (shared) /players/ # the folder that will contain all the players (AOSL interpreters) /players/aoswebplayer # a player project/subrepo There will be additional tools and players projects, and I think I'll need another folder for exporters but that's another subject. Here, what I'm trying to do, is to have a CMakeLists.txt for each project (but /language that is not source code but xsd, xml and text). Those projects will need the path of dependencies, like /tools/aosdesigner will require the path of /tools/aoslcpp. Then I want to set the paths of each project at the root level. It would be perfect if I could symply get the name of all folders in /tools/ and /players/ and simply provide them to the CMakeLists.txt of the sub projects. Is there a simple example of this kind of organisation out there that I could be inspered of? Do you have some guidance to give me to setup all this? I tried to write this organisation but I'm clueless on how to gather and provide the paths of each projects... Once I understand how to do this I think I'll use this organisation for another big project too. Any help would be really.helpful :) Thanks for reading. Tell me if I was not clear on some points. Klaim Hi Klaim, It's not completely clear to me how tightly your subprojects are coupled. I would suggest you'd create a CMake project for each of your subprojects and use the EXTERNAL_PROJECT feature to import the required subproject. UNLESS: your subprojects cannot really exist as stand-alone products, but are just parts of one overall project. In that case, I would choose to create just one CMake project. HTH, 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] Specify as in the toolchain
How can I specify the as command like I do for gcc or g++ compiler in a toolchain? SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe) ___ 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_package with ###Config.cmake
On 12/03/2010 08:45 AM, Andreas Pakulat wrote:
On 03.12.10 07:11:23, Micha Renner wrote:
There is a small library TLib which is installed like this
Install the project...
-- Install configuration: Debug
-- Installing: /usr/local/lib/libTLibd.so
-- Installing: /usr/local/lib/TLib/TLibExport.cmake
-- Installing: /usr/local/lib/TLib/TLibExport-debug.cmake
-- Installing: /usr/local/include/TLib/cmFile.h
-- Installing: /usr/local/lib/TLib/TLIBConfig.cmake
-- Installing: /usr/local/lib/TLib/TLIBConfigVersion.cmake
The CMakeLists file for the application program has the following line
to find the library
FIND_PACKAGE(TLIB)
This works, surprisingly, very good. No CMAKE_MODULE_PATH, no TLIB_DIR
in this case.
But...
If I call FIND_PACKAGE with version:
FIND_PACKAGE(TLIB 1.3)
I get the std-warning:
-
CMake Warning at TestDLL/CMakeLists.txt:20 (FIND_PACKAGE):
Could not find module FindTLIB.cmake or a configuration file for
package
TLIB.
Adjust CMAKE_MODULE_PATH or TLIB_DIR...
-
Why can't CMake find the TLIBConfig file, if FIND_PACKAGE is called with
version and TLIB_DIR is not set?
The problem might not be finding the Config file, but rather that the
ConfigVersion file doesn't set the VERSION_COMPATIBLE or VERSION_EXACT
variables. Or maybe it even sets the VERSION_UNSUITABLE to indicate that
the installed version of TLib doesn't match the version you request.
Unfortunately cmake currently cannot seem to distinguish between these
two cases (non-matching version vs. no config-file found), hence it
produces the same message in both cases.
Meanwhile, with 2.8.3 to be exact, the warning message issued by CMake
if a version file is found but the requested version doesn't suit is:
Could not find a configuration file for package ... that is compatible
with requested version
The following configuration files were considered but not accepted:
..., version: ...
So, Micha, which CMake version do you use? If it's not 2.8.3 could you
give that a try and report the message if the problem still persists?
Additionally, the package_CONSIDERED_{CONFIGS,VERSIONS} variables
would be of special interest, see dfe9c95.
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] Need some directions for non-trivial setup
Thanks for pointing EXTERNAL_PROJECT , I've looked at it but can't understand how to get the path from outside. I'll try again see if I missed something about this feature and get back to you. The projects are almost all independent and I need to allow working with a clone of one subproject without retrieving everything, just it dependencies. I'll try to be more clear : - there is a common language used to describe a Sequence (it's not important so just understand that the important projects in the framework will require this) - there are tools, all made to manipulate the sequences, so each project is independant (separate repo) but some projects need to use other projects, so we need to provide their path in their Cmake - there are players that are like tools but are just interpreter projects - anyway they are as indpendant or dependant as tools projects/subrepos - now I have central repository (default) that is just meant to gather everything together; That's for people wanting everything but they are few. Most subproject developers will just get their dependencies and work from their, without updating the dependencies while developping. If you get the default repo, you have synchronized repos togethere (read: we use specific tags for each subrespo). So the default repository is mainly for the developers needing to touch everything. Like me. Is it more clear? On Fri, Dec 3, 2010 at 11:16, Marcel Loose lo...@astron.nl wrote: On 2-12-2010 at 16:12, in message aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.comekxnbmkplnl7dn_c%2bxssgkoefm5...@mail.gmail.com, Klaim mjkl...@gmail.com wrote: Hi! I'm currently trying to understand how to use CMake for a non-trivial setup of multiple-projects-framework. I'm a beginner at CMake (as developer I mean, not as library user). I've read the docs and I tried to read the Ogre project CMake organization but it's a bit overkill for my project I think. Anyway, I'm lost here because I think I don't understand all I need to achieve what I want. My project is made of several sub projects that are all in separate (mercurial) repositories. There is one default repository that use the mercurial subrepos feature to gather everything in one big framework project. You can see the repos there : http://code.google.com/p/art-of-sequence/source/browse/ (it's an open source project but Idon't have the website ready yet to explain the concept) The Cmake organisation I want to setup I've already seen somewhere else I think, but I'm a bit lost with all the ways to do it and I think I'll make something very bad if I don't ask here for help here. I need each project (subrepo) to be available separately and can be built giving to Cmake the paths of the project's dependencies. And I need the default repo to provide the paths. So I have this folder organisation in the default repo (that gather all subrepos) : /language # the intermediate language (AOSL) definition project/subrepo /tools/# the folder that will contain all the tools projects/subrepos /tools/aosdesigner # a tool project/subrepo (in fact the most important) - an executable /tools/aoslcpp # a tool project/subrepo that is a dependency of aosdesigner - a library (shared) /players/ # the folder that will contain all the players (AOSL interpreters) /players/aoswebplayer # a player project/subrepo There will be additional tools and players projects, and I think I'll need another folder for exporters but that's another subject. Here, what I'm trying to do, is to have a CMakeLists.txt for each project (but /language that is not source code but xsd, xml and text). Those projects will need the path of dependencies, like /tools/aosdesigner will require the path of /tools/aoslcpp. Then I want to set the paths of each project at the root level. It would be perfect if I could symply get the name of all folders in /tools/ and /players/ and simply provide them to the CMakeLists.txt of the sub projects. Is there a simple example of this kind of organisation out there that I could be inspered of? Do you have some guidance to give me to setup all this? I tried to write this organisation but I'm clueless on how to gather and provide the paths of each projects... Once I understand how to do this I think I'll use this organisation for another big project too. Any help would be really.helpful :) Thanks for reading. Tell me if I was not clear on some points. Klaim Hi Klaim, It's not completely clear to me how tightly your subprojects are coupled. I would suggest you'd create a CMake project for each of your subprojects and use the EXTERNAL_PROJECT feature to import the required subproject. UNLESS: your subprojects cannot really exist as stand-alone products, but
Re: [CMake] Specify as in the toolchain
Am Freitag, 3. Dezember 2010, 13:06:41 schrieb Andrea Galeazzi: How can I specify the as command like I do for gcc or g++ compiler in a toolchain? SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe) http://www.cmake.org/Wiki/CMake/Assembler HS ___ 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] Specify as in the toolchain
Il 03/12/2010 13.15, Michael Wild ha scritto:
On 12/03/2010 01:06 PM, Andrea Galeazzi wrote:
How can I specify the as command like I do for gcc or g++ compiler in
a toolchain?
SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe)
*NEVER* set the compiler like this AFTER you executed the PROJECT or
ENABLE_LANGUAGE commands. This will cause all kinds of failures. In
fact, consider these variables to be read-only. Usually which compiler
to use is either determined by the user running CMake or by CMake itself
if the user didn't specify anything.
If you must override the compiler (really, you shouldn't), have a look
at the CMakeForceCompiler module.
The assembler is in the CMAKE_ASM${DIALECT}_COMPILER variable, but
again, consider this to be read-only. Read
http://www.cmake.org/Wiki/CMake/Assembler for more information.
Michael
__ Informazioni da ESET NOD32 Antivirus, versione del database delle
firme digitali 5670 (20101203) __
Il messaggio è stato controllato da ESET NOD32 Antivirus.
www.nod32.it
Probably my problem is simpler; that's my toolchain file for cross compile:
INCLUDE (CMakeForceCompiler)
CMAKE_FORCE_C_COMPILER (gcc.exe GNU)
CMAKE_FORCE_CXX_COMPILER (gcc.exe GNU)
# this one is important
SET(CMAKE_SYSTEM_NAME Generic)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
#this one not so much
SET(CMAKE_SYSTEM_PROCESSOR MX1)
# specify the cross compiler
SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe)
SET(CMAKE_CXX_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH C:/Programmi/development/GCCARM/bin)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER)
I'd like, when I use this toolchian, the as.exe used in makefile is
under C:/Programmi/development/GCCARM/bin (which is an ARM assembler)
instead of in the environment variable %PATH% (which is a x86 assembler)
___
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_package with ###Config.cmake
Meanwhile, with 2.8.3 to be exact, the warning message issued by CMake
if a version file is found but the requested version doesn't suit is:
Could not find a configuration file for package ... that is compatible
with requested version
The following configuration files were considered but not accepted:
..., version: ...
So, Micha, which CMake version do you use? If it's not 2.8.3 could you
give that a try and report the message if the problem still persists?
Additionally, the package_CONSIDERED_{CONFIGS,VERSIONS} variables
would be of special interest, see dfe9c95.
On Linux, I use 2.8.0, what to be is the problem.
So I switched to a Windows machine, which has 2.8.3. The warning I
mentioned above disappeared.
But a call of
FIND_PACKAGE(TLIB 1.3)
results in this message:
CMake Error at TestDLL/CMakeLists.txt:19 (FIND_PACKAGE):
Could not find a configuration file for package TLIB that is
compatible
with requested version 1.3.
The following configuration files were considered but not accepted:
C:/usr/local/lib/TLib/TLIBConfig.cmake, version: 1.3
-- TLIB_CONSIDERED_VERSIONS: 1.3
-- TLIB_CONSIDERED_CONFIGS: C:/usr/local/lib/TLib/TLIBConfig.cmake
Since my knowledge is based on CMake 2.6 Notes, there are some more
questions.
The ###ConfigVersion.cmake is still necessary?
If so, ###ConfigVersion.cmake should have at least the following
content?
SET(PACKAGE_NAME TLib)
SET(PACKAGE_VERSION 1.3)
IF(${PACKAGE_FIND_VERSION_MAJOR} EQUAL 1)
SET(PACKAGE_VERSION_COMPATIBLE 1)
IF(${PACKAGE_FIND_VERSION_MINOR} EQUAL 3)
SET(PACKAGE_VERSION_EXACT 1)# exact match for version 1.3
ENDIF(${PACKAGE_FIND_VERSION_MINOR} EQUAL 3)
ENDIF(${PACKAGE_FIND_VERSION_MAJOR} EQUAL 1)
Greetings
Micha
___
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_package with ###Config.cmake
On 03.12.10 15:19:38, Micha Renner wrote:
Meanwhile, with 2.8.3 to be exact, the warning message issued by CMake
if a version file is found but the requested version doesn't suit is:
Could not find a configuration file for package ... that is compatible
with requested version
The following configuration files were considered but not accepted:
..., version: ...
So, Micha, which CMake version do you use? If it's not 2.8.3 could you
give that a try and report the message if the problem still persists?
Additionally, the package_CONSIDERED_{CONFIGS,VERSIONS} variables
would be of special interest, see dfe9c95.
On Linux, I use 2.8.0, what to be is the problem.
So I switched to a Windows machine, which has 2.8.3. The warning I
mentioned above disappeared.
But a call of
FIND_PACKAGE(TLIB 1.3)
results in this message:
CMake Error at TestDLL/CMakeLists.txt:19 (FIND_PACKAGE):
Could not find a configuration file for package TLIB that is
compatible
with requested version 1.3.
The following configuration files were considered but not accepted:
C:/usr/local/lib/TLib/TLIBConfig.cmake, version: 1.3
-- TLIB_CONSIDERED_VERSIONS: 1.3
-- TLIB_CONSIDERED_CONFIGS: C:/usr/local/lib/TLib/TLIBConfig.cmake
Since my knowledge is based on CMake 2.6 Notes, there are some more
questions.
The ###ConfigVersion.cmake is still necessary?
Yes.
If so, ###ConfigVersion.cmake should have at least the following
content?
Can you try using VERSION_(EQUAL|GREATER|LESS) instead of just EQUAL and
please also try wether setting the variables (PACKAGE_VERSION_XXX) to TRUE
rather than 1 changes anything.
In worst case you'll have to add some message() output to the Version file
to see why its not setting the variables correctly.
Andreas
--
Blow it out your ear.
___
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] providing library information, what's the cmake way
On Wednesday 01 December 2010 17:57:45 Johannes Zarl wrote: Back to my proposed FPCHSA: My initial goal was to provide an interface which does as much work as possible for you, maybe at the price of restricted variable naming. So let's come up with a better interface: I do want to restrict the possible prefix for modules, because I really do think it is a good practice (and a practice worth enforcing) to require a common package prefix and one prefix for each component): FPCHSA( XXX DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS COMPONENT YYY DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS COMPONENT ZZZ DEFAULT_MSG INCLUDE_DIR OTHER_VAR ) This is far noisier than the initial approach, but still much easier to read and more compact to write that the FPHSA approach outlined above (3 lines vs. 7 lines). Even without the namespace-enforcement it would be readable: FPCHSA( XXX DEFAULT_MSG XXX_LIBRARY XXX_INCLUDE_DIR XXX_DEFINITIONS COMPONENT YYY DEFAULT_MSG XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR XXX_YYY_DEFINITIONS COMPONENT ZZZ DEFAULT_MSG XXX_YYY_INCLUDE_DIR XXX_YYY_OTHER_VAR ) This signature should even be downwards-compatible with FPHSA. Btw. I just read the documentation for the new FPHSA: I do think that the COMPONENT keyword would actually fit in quite well into the new interface. I guess the FindPackageHandleStandardArgs-maintainer is reading this list: What do you think about adding component support? Cheers, Johannes ___ 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] Linking archives in a sibling directory
Hi Michael,
Thank you for your continued advice!
On Fri, Dec 3, 2010 at 19:13, Michael Hertling mhertl...@online.de wrote:
On 12/02/2010 03:13 PM, Raymond Wan wrote:
ADD_SUBDIRECTORY (dir-A)
before
ADD_SUBDIRECTORY (main)
then main will be built correctly?
Even this is not necessary if the only reference of main to dir-A is
TARGET_LINK_LIBRARIES(... subprogA_ar) in main/CMakeLists.txt since
TARGET_LINK_LIBARIES(), AFAIK, does a lazy evaluation of the targets'
dependencies, i.e. they are evaluated when all CMakeLists.txt files
have been processed and, hence, all dependencies are known. If you
refer to subprogA_ar in another way, e.g. SET_TARGET_PROPERTIES(),
then you will get an error if dir-A hasn't been configured yet.
I see; I am using just TARGET_LINK_LIBRARIES (), so that is good to
know that I don't need to worry about the ordering. Thank you!
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
yet this kind of duplication should be an error at worse; unnecessary
repetition at best?
Each invocation of ADD_SUBDIRECTORY() for a source directory must be
associated with an own binary directory, so the above-mentioned line
would allow you to use both alternatives. However, when configuring
the top-level CMakeLists.txt, you will get an error due to multiple
definitions of the subprogA_ar target. In main/CMakeLists.txt, you
might protect ADD_SUBDIRECTORY() against multiple invocations like
IF(NOT TARGET subprogA_ar)
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
or
IF(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
but this does not appear really appropriate to me.
Nevertheless, I wonder why you want to build main by configuring its
own source directory and alternatively via the top-level directory. If
this is because you'd like to exclude some modules from building, you
should handle such things in the top-level CMakeLists.txt, e.g. like:
# Define options:
OPTION(WITH_MAIN Build module main ON)
OPTION(WITH_A Build module A ON)
OPTION(WITH_B Build module B ON)
# Handle dependencies:
IF(WITH_MAIN)
SET(WITH_A ON)
ENDIF()
# Enable modules:
IF(WITH_B)
ADD_SUBDIRECTORY(dir-B)
ENDIF()
IF(WITH_A)
ADD_SUBDIRECTORY(dir-A)
ENDIF()
IF(WITH_MAIN)
ADD_SUBDIRECTORY(main)
ENDIF()
So, you can conveniently enable/disable the modules on the command line
or in the GUI, e.g. with cmake -DWITH_B=OFF path/to/top-level-dir
if you don't want to build module B.
As an alternative, you might consider to move dir-A to main/dir-A if
dir-A is essentially a submodule of main, but referring to a sibling
dir-A from main indicates that the latter is not sufficiently self-
contained to be built on its own with a cmake path/to/main, so
the modules' relationships should be handled by other means, IMO.
Hm, I see your point about why I'm providing support in a
top-level CMakeLists.txt and a lower level one. Perhaps I've simply
confused myself and made things more complicated than it needs to be.
Basically, what I want to do is, given this directory structure:
myproj/
+dirA/
+dirB/
+dirC/
+main1/
+main2/
+main3/
my final goal is that several programs (i.e., executables) will be
made. Let's say main1, main2, and main3. The libraries dirA, ...,
dirD are used by them and can also depend on each other with maybe
even multiple levels of dependencies. i.e.,
dirA -- dirB -- dirC
Any of these modules can be used by more than one program. i.e.,
main1 -- dirA -- dirB -- dirC
main2 -- dirC
My idea is that the top level CMakeLists.txt can create main1, main2,
and main3. The lower level CMakeLists.txt in dirA/, dirB/, and dirC/
have their own main () which I am using to test them -- obviously,
these main () functions are not linked into main1, main2, and main3.
I only need them for development. I think organizing dirA/, dirB/,
and dirC/ within main1/, main2/, and main3/ isn't the way to go since
these libraries are used by multiple executables.
Perhaps I should create and use the low-level CMakeLists.txt and when
I am finished development, then create the top-level ones for just
main1, main2, and main3. In a way, I will only need to support either
the top-level CMakeLists.txt or the lower level one and never both at
the same time. I guess I am ahead of myself and did both now, which
is complicating things for me.
H, I need to give this a bit more thought -- any suggestions
welcome... Thank you!
Ray
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem setting ENVIRONMENT for ctest
Dear all,
I am try to set the PATH environment variable on windows for running the
unit tests through ctest. The ctest file is generated by the cmake
scripts. The PATH is required to for finding additional dlls required by
the tests.
I tried to set the PATH using this cmake code:
SET(PATH_STRING $ENV{PATH};${Boost_LIBRARY_DIRS})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=${PATH_STRING})
This is done according to this list posting some time ago:
http://www.cmake.org/pipermail/cmake/2009-May/029464.html
However, it does not work for me. PATH is not changed when calling ctest
and the dlls are not found. I investigated a bit and found out that the
resulting CTestTestfile.cmake file contains these lines for every
specified test:
ADD_TEST(rsbtest correct binary)
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=correct path
with correct escapes)
However, man ctest does not even document that SET_TESTS_PROPERTIES is
a valid command for ctest. Instead SET_PROPERTY(TEST...) is explained.
So I changed the generated CTestTestfile.cmake according to this
information to:
ADD_TEST(rsbtest correct binary)
SET_PROPERTY(TEST rsbtest PROPERTY ENVIRONMENT PATH=correct path with
correct escapes)
Afterwards all unit tests run as expected.
What am I doing wrong here? Or is this a bug in cmake?
Thanks for any help!
Johannes
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem setting ENVIRONMENT for ctest
What version of cmake/ctest are you using?
(i.e. -- send the output of cmake --version)
What does CTestTestfile.cmake contain if you change your CMakeLists
file to use set_property(TEST ...) instead of set_tests_properties()?
This should work as expected in CMake. We have a test in the test
suite that tests the ENVIRONMENT test property at
CMake/Tests/Environment/CMakeLists.txt -- the test uses
set_tests_properties.
???
David
On Fri, Dec 3, 2010 at 12:37 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Dear all,
I am try to set the PATH environment variable on windows for running the
unit tests through ctest. The ctest file is generated by the cmake scripts.
The PATH is required to for finding additional dlls required by the tests.
I tried to set the PATH using this cmake code:
SET(PATH_STRING $ENV{PATH};${Boost_LIBRARY_DIRS})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=${PATH_STRING})
This is done according to this list posting some time ago:
http://www.cmake.org/pipermail/cmake/2009-May/029464.html
However, it does not work for me. PATH is not changed when calling ctest and
the dlls are not found. I investigated a bit and found out that the
resulting CTestTestfile.cmake file contains these lines for every specified
test:
ADD_TEST(rsbtest correct binary)
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=correct path
with correct escapes)
However, man ctest does not even document that SET_TESTS_PROPERTIES is a
valid command for ctest. Instead SET_PROPERTY(TEST...) is explained. So I
changed the generated CTestTestfile.cmake according to this information to:
ADD_TEST(rsbtest correct binary)
SET_PROPERTY(TEST rsbtest PROPERTY ENVIRONMENT PATH=correct path with
correct escapes)
Afterwards all unit tests run as expected.
What am I doing wrong here? Or is this a bug in cmake?
Thanks for any help!
Johannes
___
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] Problem setting ENVIRONMENT for ctest
Hey,
thanks for the quick reply.
Am 03.12.2010 19:12 schrieb David Cole:
What version of cmake/ctest are you using?
(i.e. -- send the output of cmake --version)
On the windows machine (32 bit) where the problem is visible it is
2.8.3. I could also verify the generated CTestTestfile on linux 64 bit
with 2.8.0.
What does CTestTestfile.cmake contain if you change your CMakeLists
file to use set_property(TEST ...) instead of set_tests_properties()?
The same content that does not work.
This should work as expected in CMake. We have a test in the test
suite that tests the ENVIRONMENT test property at
CMake/Tests/Environment/CMakeLists.txt -- the test uses
set_tests_properties.
I took a look at the contents of that test and transferred it to my
project printing out the PATH environment variable. There I found two
things: a) an inconsistent behavior and b) the real problem. ;)
a)
I had the correct path required for running the tests exported on the
shell prior to calling ctest. With the SET_TESTS_PROPERTIES test file
version generated by cmake this is ignored (PATH is completely replaced
by the contents of the test file) whereas the SET_PROPERTIES(TEST...)
version (modified by hand) seems to append to the current path instead
of replacing it and hence passed through the correct export from my
shell to the test executable.
b)
The real problem is that the system path of my machine contains an entry
that ends with a slash (completely legal):
...tem32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\...
(end of the powershell entry)
Using the regular expression above to escape the semicolons results in:
...tem32\Wbem\;C:\Windows\System32\WindowsPowerShell\v1.0\\;C:\...
You see the double-slash.
Using this string again in the SET_TESTS_PROPERTIES macro again results
in a path truncated after this entry because everything after the
powershell entry is misinterpreted by the macro as a new environment
variable or I don't know.
So the real question is how to handle this case correctly? The need to
escape the semicolons seems to be a burden for users that isn't event
documented and in this case results in a error which requires strange
corner cases routines.
Regards,
Johannes
On Fri, Dec 3, 2010 at 12:37 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Dear all,
I am try to set the PATH environment variable on windows for running the
unit tests through ctest. The ctest file is generated by the cmake scripts.
The PATH is required to for finding additional dlls required by the tests.
I tried to set the PATH using this cmake code:
SET(PATH_STRING $ENV{PATH};${Boost_LIBRARY_DIRS})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=${PATH_STRING})
This is done according to this list posting some time ago:
http://www.cmake.org/pipermail/cmake/2009-May/029464.html
However, it does not work for me. PATH is not changed when calling ctest and
the dlls are not found. I investigated a bit and found out that the
resulting CTestTestfile.cmake file contains these lines for every specified
test:
ADD_TEST(rsbtest correct binary)
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=correct path
with correct escapes)
However, man ctest does not even document that SET_TESTS_PROPERTIES is a
valid command for ctest. Instead SET_PROPERTY(TEST...) is explained. So I
changed the generated CTestTestfile.cmake according to this information to:
ADD_TEST(rsbtest correct binary)
SET_PROPERTY(TEST rsbtest PROPERTY ENVIRONMENT PATH=correct path with
correct escapes)
Afterwards all unit tests run as expected.
What am I doing wrong here? Or is this a bug in cmake?
Thanks for any help!
Johannes
___
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
signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem setting ENVIRONMENT for ctest
Try just the single line:
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT
PATH=$ENV{PATH};${Boost_LIBRARY_DIRS})
Or... if there's still a \; problem with that call, then try it this
way, reversing the ordering:
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT
PATH=${Boost_LIBRARY_DIRS};$ENV{PATH})
Let us know if that works.
It's not documented, because where would we document something like
that so that it would be useful and found by someone looking for it.
The best solution is google first, email here second... :-)
Thanks,
David
On Fri, Dec 3, 2010 at 3:49 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Hey,
thanks for the quick reply.
Am 03.12.2010 19:12 schrieb David Cole:
What version of cmake/ctest are you using?
(i.e. -- send the output of cmake --version)
On the windows machine (32 bit) where the problem is visible it is
2.8.3. I could also verify the generated CTestTestfile on linux 64 bit
with 2.8.0.
What does CTestTestfile.cmake contain if you change your CMakeLists
file to use set_property(TEST ...) instead of set_tests_properties()?
The same content that does not work.
This should work as expected in CMake. We have a test in the test
suite that tests the ENVIRONMENT test property at
CMake/Tests/Environment/CMakeLists.txt -- the test uses
set_tests_properties.
I took a look at the contents of that test and transferred it to my
project printing out the PATH environment variable. There I found two
things: a) an inconsistent behavior and b) the real problem. ;)
a)
I had the correct path required for running the tests exported on the
shell prior to calling ctest. With the SET_TESTS_PROPERTIES test file
version generated by cmake this is ignored (PATH is completely replaced
by the contents of the test file) whereas the SET_PROPERTIES(TEST...)
version (modified by hand) seems to append to the current path instead
of replacing it and hence passed through the correct export from my
shell to the test executable.
b)
The real problem is that the system path of my machine contains an entry
that ends with a slash (completely legal):
...tem32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\...
(end of the powershell entry)
Using the regular expression above to escape the semicolons results in:
...tem32\Wbem\;C:\Windows\System32\WindowsPowerShell\v1.0\\;C:\...
You see the double-slash.
Using this string again in the SET_TESTS_PROPERTIES macro again results
in a path truncated after this entry because everything after the
powershell entry is misinterpreted by the macro as a new environment
variable or I don't know.
So the real question is how to handle this case correctly? The need to
escape the semicolons seems to be a burden for users that isn't event
documented and in this case results in a error which requires strange
corner cases routines.
Regards,
Johannes
On Fri, Dec 3, 2010 at 12:37 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Dear all,
I am try to set the PATH environment variable on windows for running the
unit tests through ctest. The ctest file is generated by the cmake scripts.
The PATH is required to for finding additional dlls required by the tests.
I tried to set the PATH using this cmake code:
SET(PATH_STRING $ENV{PATH};${Boost_LIBRARY_DIRS})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=${PATH_STRING})
This is done according to this list posting some time ago:
http://www.cmake.org/pipermail/cmake/2009-May/029464.html
However, it does not work for me. PATH is not changed when calling ctest and
the dlls are not found. I investigated a bit and found out that the
resulting CTestTestfile.cmake file contains these lines for every specified
test:
ADD_TEST(rsbtest correct binary)
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=correct path
with correct escapes)
However, man ctest does not even document that SET_TESTS_PROPERTIES is a
valid command for ctest. Instead SET_PROPERTY(TEST...) is explained. So I
changed the generated CTestTestfile.cmake according to this information to:
ADD_TEST(rsbtest correct binary)
SET_PROPERTY(TEST rsbtest PROPERTY ENVIRONMENT PATH=correct path with
correct escapes)
Afterwards all unit tests run as expected.
What am I doing wrong here? Or is this a bug in cmake?
Thanks for any help!
Johannes
___
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
Re: [CMake] Problem setting ENVIRONMENT for ctest
Ok, so just as a start, the PATH of the shell is:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program
Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft
Visual Studio
9.0\Common7\Tools;C:\Windows\Microsoft.NET\Framework\v3.5;C:\Windows\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program
Files\\Microsoft
SDKs\Windows\v6.0A\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\CMake 2.8\bin;C:\Program
Files\TortoiseSVN\bin;C:\MinGW\msys\1.0;C:\MinGW\msys\1.0\bin
Am 03.12.2010 22:26 schrieb David Cole:
Try just the single line:
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT
PATH=$ENV{PATH};${Boost_LIBRARY_DIRS})
This results in the following path being exported to the test program:
Environment:
PATH='C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE'
Or... if there's still a \; problem with that call, then try it this
way, reversing the ordering:
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT
PATH=${Boost_LIBRARY_DIRS};$ENV{PATH})
Environment:
PATH='C:/Program Files/boost/boost_1_44/lib'
So you really have to escape the semicolons, otherwise only the first
path entry is passed to the program.
My solution that works now is a two-step replace procedure:
STRING(REPLACE \\; ; PATH_STRING ${PATH_STRING})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
But this is really ugly. There must be a better solution or fix for
setting this property.
It's not documented, because where would we document something like
that so that it would be useful and found by someone looking for it.
The best solution is google first, email here second... :-)
In the section Properties on tests in the man page. ;) At least I
looked up the ENVIRONMENT property there and I'm sure others will do the
same.
Cheers,
Johannes
On Fri, Dec 3, 2010 at 3:49 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Hey,
thanks for the quick reply.
Am 03.12.2010 19:12 schrieb David Cole:
What version of cmake/ctest are you using?
(i.e. -- send the output of cmake --version)
On the windows machine (32 bit) where the problem is visible it is
2.8.3. I could also verify the generated CTestTestfile on linux 64 bit
with 2.8.0.
What does CTestTestfile.cmake contain if you change your CMakeLists
file to use set_property(TEST ...) instead of set_tests_properties()?
The same content that does not work.
This should work as expected in CMake. We have a test in the test
suite that tests the ENVIRONMENT test property at
CMake/Tests/Environment/CMakeLists.txt -- the test uses
set_tests_properties.
I took a look at the contents of that test and transferred it to my
project printing out the PATH environment variable. There I found two
things: a) an inconsistent behavior and b) the real problem. ;)
a)
I had the correct path required for running the tests exported on the
shell prior to calling ctest. With the SET_TESTS_PROPERTIES test file
version generated by cmake this is ignored (PATH is completely replaced
by the contents of the test file) whereas the SET_PROPERTIES(TEST...)
version (modified by hand) seems to append to the current path instead
of replacing it and hence passed through the correct export from my
shell to the test executable.
b)
The real problem is that the system path of my machine contains an entry
that ends with a slash (completely legal):
...tem32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\...
(end of the powershell entry)
Using the regular expression above to escape the semicolons results in:
...tem32\Wbem\;C:\Windows\System32\WindowsPowerShell\v1.0\\;C:\...
You see the double-slash.
Using this string again in the SET_TESTS_PROPERTIES macro again results
in a path truncated after this entry because everything after the
powershell entry is misinterpreted by the macro as a new environment
variable or I don't know.
So the real question is how to handle this case correctly? The need to
escape the semicolons seems to be a burden for users that isn't event
documented and in this case results in a error which requires strange
corner cases routines.
Regards,
Johannes
On Fri, Dec 3, 2010 at 12:37 PM, Johannes Wienke
jwie...@techfak.uni-bielefeld.de wrote:
Dear all,
I am try to set the PATH environment variable on windows for running the
unit tests through ctest. The ctest file is generated by the cmake scripts.
The PATH is required to for finding additional dlls required by the tests.
I tried to set the PATH using this cmake code:
SET(PATH_STRING $ENV{PATH};${Boost_LIBRARY_DIRS})
STRING(REPLACE ; \\; PATH_STRING ${PATH_STRING})
SET_TESTS_PROPERTIES(rsbtest PROPERTIES ENVIRONMENT PATH=${PATH_STRING})
This is done according to this list posting some time ago:
http://www.cmake.org/pipermail/cmake/2009-May/029464.html
However, it does not work for me. PATH is not
[CMake] Patch CMake for Mac static library creation
Hi, I'm on Mac OSX 10.5.8 with Intel 12.x compilers and CMake version 2.8.3. CMake doesn't seem to add the -c option to the ranlib command to include common symbols into the library table of contents. Here's the documentation for Apple's ranlib. -c Include common symbols as definitions with respect to the table of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ranlib. This option is not the default. This behavior is necessary if you have Fortran 90 modules that define data but that don't contain any code (or contains code that isn't called). Can -c be added by default when creating static Fortran libraries on the Mac using ranlib? Thanks. -- Noel Belcourt ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.3-155-g34ee41b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 34ee41b9cca39cf6d22fa788c0df8bc56d92b33c (commit) from 4617135fe773fe7a95628788e7a542db8614d1b7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=34ee41b9cca39cf6d22fa788c0df8bc56d92b33c commit 34ee41b9cca39cf6d22fa788c0df8bc56d92b33c Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Dec 4 00:01:05 2010 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Dec 4 00:10:02 2010 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 3b506bb..298 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 03) +SET(KWSYS_DATE_STAMP_DAY 04) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
