Re: [CMake] Modules with additional files
Am 29.12.2010 19:22 schrieb Michael Jackson:
You want to do something like this:
# In the CMake file get the parent directory of the current
# cmake file that is being parsed
get_filename_component( CURRENT_DIR ${CMAKE_CURRENT_LIST_FILE} ABSOLUTE)
configure_file ( ${CURRENT_DIR}/SomeFile.h.in .. )
Is that what you were looking for?
The problem is that I am not in a list file, but in a module. Hence,
CMAKE_CURRENT_LIST_FILE does not work.
For example I got a module that test some features using a cpp file that
needs to be try-compiled and I now need a way to locate this cpp-file.
All default cmake modules use something like CMAKE_ROOT, but I cannot
assume this.
Regards,
Johannes
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] Modules with additional files
Am 29.12.2010 19:53 schrieb Michael Jackson:
--
Mike Jackson www.bluequartz.net
On Dec 29, 2010, at 1:51 PM, Johannes Wienke wrote:
Am 29.12.2010 19:22 schrieb Michael Jackson:
You want to do something like this:
# In the CMake file get the parent directory of the current
# cmake file that is being parsed
get_filename_component( CURRENT_DIR ${CMAKE_CURRENT_LIST_FILE} ABSOLUTE)
configure_file ( ${CURRENT_DIR}/SomeFile.h.in .. )
Is that what you were looking for?
The problem is that I am not in a list file, but in a module. Hence,
CMAKE_CURRENT_LIST_FILE does not work.
For example I got a module that test some features using a cpp file that
needs to be try-compiled and I now need a way to locate this cpp-file.
All default cmake modules use something like CMAKE_ROOT, but I cannot
assume this.
Regards,
Johannes
I don't understand what you mean by a module. If you are in a
CMakeLists.txt or *.cmake file that is being parsed by CMake then you have
access to CMAKE_CURRENT_LIST_FILE. I think I am missing something about your
particular setup. Maybe some more details would help us.
Confusing, I thought I checked this twice that CMAKE_CURRENT_LIST_*
always only points to CMakeLists.txt files, but it works perfectly. ;)
Thanks alot, I must have been really tired. ;)
Cheers,
Johannes
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] Modules with additional files
Hey again, Am 29.12.2010 20:23 schrieb Johannes Wienke: Am 29.12.2010 19:53 schrieb Michael Jackson: I don't understand what you mean by a module. If you are in a CMakeLists.txt or *.cmake file that is being parsed by CMake then you have access to CMAKE_CURRENT_LIST_FILE. I think I am missing something about your particular setup. Maybe some more details would help us. Confusing, I thought I checked this twice that CMAKE_CURRENT_LIST_* always only points to CMakeLists.txt files, but it works perfectly. ;) Thanks alot, I must have been really tired. ;) Ok, now I understand my original problem: In one of these modules there is a function defined which originally used CMAKE_CURRENT_LIST_DIR. When this function is used, CMAKE_CURRENT_LIST_DIR is set to the list file of the function caller. Somehow I would have expected this behavior only for macros and not for functions. Is this intended? Johannes 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] Modules with additional files
Am 29.12.2010 21:47 schrieb David Cole:
Variables inside functions inherit their values from the calling
scope. If you need the value of the CMAKE_CURRENT_LIST_DIR in a
function that points to the directory containing the file that the
function is defined in, then you should do something like this:
# MyModule.cmake
set(MyModule_DIR ${CMAKE_CURRENT_LIST_DIR})
# important that this set call is at file scope outside of function
declarations...
function(that_needs_list_dir ...)
set(dir MyModule_DIR)
# use ${dir} here if necessary
endfunction()
Thanks, I already did something like that.
Of course, you're subject to global variable name clashes at this
point so the global variable name should somehow incorporate the
name of the file it lives in, and perhaps be named more cleverly than
my example here so that you can avoid colliding with some other
module's variable name.
Ok. Good to know.
More context (sample code from your modules) would help us answer your
questions more effectively
By the way, CMAKE_CURRENT_LIST_DIR is new. It's only in CMake 2.8.3 and later.
Thanks for the reminder.
Johannes
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
[CMake] Modules with additional files
Hey,
I've got a library that provides several cmake modules and also uses
them. Some of these modules have additional files, e.g. to be used with
CONFIGURE_FILE. The question is, how do I locate these additional files
so that they work in both cases, in project and installed?
${CMAKE_ROOT}/Modules is of course not working and is also a bad
assumption for multi-user systems where not everyone is admin. Something
like CMAKE_CURRENT_MODULE_DIR would be ideal for my case... Is there a
general solution for this problem?
Thanks for helping,
Johannes
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
[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
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
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
