RE: [CMake] function and raise_scope commands
1. CMake crashes if I use the same variable name as the argument and
raise the scope later. That is, for the following function:
function(track_find_variable cache_variable is_changed)
raise_scope(${is_changed})
endfunction(track_find_variable)
I can't call it like:
track_find_variable(testvar is_changed) # I had to mangle is_changed
above, but that's ok
I think it shouldn't crash. If its too much effort to have cmake
support this, then I don't think it is worth it... just having a note
that the argument can't be used as a variable name in the help and
maybe try to detect the case and signal an error...
This still doesn't work. I don't know if you have done anything for this.
Actually the code above works for me. If you add a set command of the
variable before the raise scope then I see the problem you describe. The
variable that has the name of the variable in it (is_changed) gets
overridden because it has the same name as its value.
Specifically
Variable value
is_changed is_changed
set(${is_changed} some_result)
is_changed some_result
raise_scope(${is_changed})
well this last line becomes raise_scope(some_result) and since there is no
local variable named some_result it yerks. I have fixed the crash and it now
prints a nice warning message (on my local copy of cmake, not checked in
yet) but I'm not sure that is all the solution. I think a safer fix may be
to change the raise scope command to look like the following:
raise_scope(var_name value var_name value ...)
with a convention that you do not set variables that are to be returned (aka
passed by reference). In this case that would be is_changed. You leave
is_changed alone and only use it in the raise scope command. So the
resulting code would look like.
function(track_find_variable cache_variable is_changed)
set(changed some_result)
raise_scope(${is_changed} ${changed})
endfunction(track_find_variable)
which is safer. But I am still want to think about it a bit before I commit
the change.
3. I'm having another issue. If you pass a variable to a function that
hasn't been defined previously and that isn't defined in the function
either, then it crashes when you do a raise_scope on it.
For instance, if you have the following function:
Pretty sure I have fixed this on my local copy of the code. I'll check it in
with the above fixes in a few days (still on vacation for a few more days)
Thanks
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] function and raise_scope commands
On Dec 28, 2007 11:36 AM, Ken Martin wrote:
1. CMake crashes if I use the same variable name as the argument and
raise the scope later. That is, for the following function:
snip
Specifically
Variable value
is_changed is_changed
set(${is_changed} some_result)
is_changed some_result
raise_scope(${is_changed})
well this last line becomes raise_scope(some_result) and since there is no
local variable named some_result it yerks. I have fixed the crash and it now
prints a nice warning message (on my local copy of cmake, not checked in
yet) but I'm not sure that is all the solution. I think a safer fix may be
to change the raise scope command to look like the following:
raise_scope(var_name value var_name value ...)
with a convention that you do not set variables that are to be returned (aka
passed by reference). In this case that would be is_changed. You leave
is_changed alone and only use it in the raise scope command. So the
resulting code would look like.
function(track_find_variable cache_variable is_changed)
set(changed some_result)
raise_scope(${is_changed} ${changed})
endfunction(track_find_variable)
which is safer. But I am still want to think about it a bit before I commit
the change.
Well, I think the above is fine, but it's the convention of not using
the variable that is solving the problem not the command syntax. That
is, if you do a set(is_changed ...) before the raise_scope you still
get into trouble.
I think printing a warning when the argument contains the same name as
the variable, and just have the convention of putting an underscore in
front of the argument should work as well:
function(track_find_variable _cache_variable _is_changed)
At least, that is what I'm doing and it is simple to stick to it.
3. I'm having another issue. If you pass a variable to a function that
hasn't been defined previously and that isn't defined in the function
either, then it crashes when you do a raise_scope on it.
For instance, if you have the following function:
Pretty sure I have fixed this on my local copy of the code. I'll check it in
with the above fixes in a few days (still on vacation for a few more days)
Thanks.
--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Install of pattern matched files
Hi, I've been using the install command and I'm missing a feature to only install files matching a certain pattern. There's a way to exclude files, but it's too cumbersome to specify all patterns that I don't want to be installed, it's easier to specify patterns of files to be installed. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake and xcode question
Hi all, I was able to generate an xcode project from a cmake file. I was wondering, is there any way that we can encapsulate svn configurations in a cmake file so when I generate xcode project and import it into xcode, the project is automatically configured to work with the svn configuration? I am using Mac 10.5 and xcode 3.0. I was able to successfully configure svn but I wasn't able to link it to my cmake generated xcode project. I would love for this whole process to be seemlessly connected, and all I need is to run cmake and I have an xcode project along with the svn configuration. Thank you. Moe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Install of pattern matched files
On Dec 28, 2007 11:59 AM, Rodolfo Lima [EMAIL PROTECTED] wrote: Hi, I've been using the install command and I'm missing a feature to only install files matching a certain pattern. There's a way to exclude files, but it's too cumbersome to specify all patterns that I don't want to be installed, Too cumbersome? Surely you jest. What's a long-winded list of patterns in terms of your development time? Two minutes tops? it's easier to specify patterns of files to be installed. Sure, it's easier. Sounds like a low priority feature request to me. File it in the bug tracker. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Eclipse
I have another question... I did notice that eclipse 3.3 has become extremely impressive on C/C++ development front. I am more inclined now to give it a shot to see if it can provide me with more than what xcode 3.0 can for C/C++ programming. Especially since I am a Java eclipse user. Now, I know there were some work-arounds posted on the Internet to get eclipse to work with cmake. I would like to know if people have used eclipse 3.3 and have something to say about how it compares to xcode 3.0, and what they did to get cmake working with eclipse easier than other work-around methods. Thank you. Moe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
Brandon Van Every escreveu: Too cumbersome? Surely you jest. What's a long-winded list of patterns in terms of your development time? Two minutes tops? Oh well... thanks for teaching me another word: jest, and I'm not being ironic. Back to business... imagine the following use case: a project mixes headers and source files all inside the same directory, along with other files. During install, I want to get all headers and copy to prefix/include/mylib. That's it. I think this is a very common scenario. Right now I'm using cmake to compile and install external libraries needed for my project that aren't installed by default in the build system. Say I need to upgrade this library... I don't want to mess with the build/install recipe again just to add a possibly new file that was added. What I'm doing right now is getting the header names using file(GLOB ...) then installing them, but this is not a direct solution (as PATTERN ... EXCLUDE is). Sure, it's easier. Sounds like a low priority feature request to me. File it in the bug tracker. I could implement it if I knew that it would be committed to cvs, that's why I posted the idea here first. Happy new year, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
Can't you use PATTERN without the EXCLUDE to achieve this? On 12/28/07, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: Too cumbersome? Surely you jest. What's a long-winded list of patterns in terms of your development time? Two minutes tops? Oh well... thanks for teaching me another word: jest, and I'm not being ironic. Back to business... imagine the following use case: a project mixes headers and source files all inside the same directory, along with other files. During install, I want to get all headers and copy to prefix/include/mylib. That's it. I think this is a very common scenario. Right now I'm using cmake to compile and install external libraries needed for my project that aren't installed by default in the build system. Say I need to upgrade this library... I don't want to mess with the build/install recipe again just to add a possibly new file that was added. What I'm doing right now is getting the header names using file(GLOB ...) then installing them, but this is not a direct solution (as PATTERN ... EXCLUDE is). Sure, it's easier. Sounds like a low priority feature request to me. File it in the bug tracker. I could implement it if I knew that it would be committed to cvs, that's why I posted the idea here first. Happy new year, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
David Cole escreveu: Can't you use PATTERN without the EXCLUDE to achieve this? Unfortunately no. Documentation doesn't say anything about it and I've already tried without success. Thanks, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
Just adding to this, I thought I had it figured out also but I can't
do this either. My project is laid out like the following:
Project
CMakeLists.txt
src
lib
test
and I would like to install all the header files from Project/src/
lib/*.h into ${CMAKE_INSTALL_PREFIX}/include/mylib.
I tried the following and I pick up all the files, including the
cvs files..
INSTALL(DIRECTORY src/
DESTINATION include/MXADataModel
REGEX .*\\.h$
)
which I think should work. So what am I doing wrong?
--
Mike Jackson
imikejackson gmail * com
On Dec 28, 2007, at 2:51 PM, Rodolfo Lima wrote:
David Cole escreveu:
Can't you use PATTERN without the EXCLUDE to achieve this?
Unfortunately no. Documentation doesn't say anything about it and I've
already tried without success.
Thanks,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 1:33 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: Too cumbersome? Surely you jest. What's a long-winded list of patterns in terms of your development time? Two minutes tops? Oh well... thanks for teaching me another word: jest, and I'm not being ironic. Back to business... imagine the following use case: a project mixes headers and source files all inside the same directory, along with other files. During install, I want to get all headers and copy to prefix/include/mylib. That's it. I think this is a very common scenario. Do the REGEX and/or REGEX ... EXCLUDE signatures work? If so, then this is a low priority feature request. A PATTERN spares the programmer from having to learn how regexes work, but specifying these kinds of inclusions and exclusions with regexes is trivial. Sure, it's easier. Sounds like a low priority feature request to me. File it in the bug tracker. I could implement it if I knew that it would be committed to cvs, that's why I posted the idea here first. Can't imagine why it wouldn't be. You say it's easy to implement, and it's not controversial. Happy new year, Indeed! Same. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 2:51 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: David Cole escreveu: Can't you use PATTERN without the EXCLUDE to achieve this? Unfortunately no. Documentation doesn't say anything about it What version of CMake are you using? CMake 2.4.7 documentation says plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should work fine without an EXCLUDE and I've already tried without success. If you're using CMake 2.4.7 and can reproduce that with a simple test case, it's a bug. File it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:38 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 28, 2007 2:51 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: David Cole escreveu: Can't you use PATTERN without the EXCLUDE to achieve this? Unfortunately no. Documentation doesn't say anything about it What version of CMake are you using? CMake 2.4.7 documentation says plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should work fine without an EXCLUDE Ok, now I get it. You're not using the INSTALL(DIRECTORY ...) signature. You're using the INSTALL(FILES ...) signature, and you're asking for PATTERN and PATTERN ... EXCLUDE to be available for that signature. Is that a good idea? Dunno, I don't have my brain cells wrapped around it at the moment. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:33 PM, Mike Jackson [EMAIL PROTECTED] wrote: INSTALL(DIRECTORY src/ DESTINATION include/MXADataModel REGEX .*\\.h$ ) which I think should work. So what am I doing wrong? The regex is correct. What happens if you use src instead of src/ ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007, at 4:51 PM, Brandon Van Every wrote: On Dec 28, 2007 4:33 PM, Mike Jackson [EMAIL PROTECTED] wrote: INSTALL(DIRECTORY src/ DESTINATION include/MXADataModel REGEX .*\\.h$ ) which I think should work. So what am I doing wrong? The regex is correct. What happens if you use src instead of src/ ? Cheers, Brandon Van Every I used the following: INSTALL(DIRECTORY src DESTINATION include/MXADataModel REGEX .*\\.h$ ) and I get EVERY file located in the src directory, including all subdirectories. By all files I mean EVERYTHING. CVS files, headers, sources.. everything. Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007, at 4:51 PM, Brandon Van Every wrote: On Dec 28, 2007 4:33 PM, Mike Jackson [EMAIL PROTECTED] wrote: INSTALL(DIRECTORY src/ DESTINATION include/MXADataModel REGEX .*\\.h$ ) which I think should work. So what am I doing wrong? The regex is correct. What happens if you use src instead of src/ ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake I should also note that I am using cmake 2.4.7 compiled on my OS X 10.4.11 system.. Just for the record -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] /MACHINE:x64
Hi CMakers!
I am trying to compile on a 64 bit windows machine (AMD64). It seems
CMake only outputs /MACHINE:X64 for the link flags. However,
link.exe reports that flag doesn't exist. Is this a bug?
I am using,
cmake version 2.4-patch 7
cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
link.exe
Microsoft (R) Incremental Linker Version 8.00.40310.39
Copyright (C) Microsoft Corporation. All rights reserved.
options for /MACHINE: from link.exe /?
/MACHINE:{AM33|AMD64|ARM|CEE|EBC|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
MIPSR41XX|SH4|SH5|THUMB|X86}
Let me know if you need more info.
Thanks,
George.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:55 PM, Mike Jackson [EMAIL PROTECTED] wrote: I used the following: INSTALL(DIRECTORY src DESTINATION include/MXADataModel REGEX .*\\.h$ ) and I get EVERY file located in the src directory, including all subdirectories. By all files I mean EVERYTHING. CVS files, headers, sources.. everything. I bet the CMake code that implements this has some unwarranted assumptions about what kind of regex is going to be passed. I bet the .* is matching against some list of files, and therefore matching any *list* that terminates with the pattern. Or it's just written wrong in some other way. Anyways it's a bug. Write a trivial reproducer and file it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
Mike Jackson escreveu: INSTALL(DIRECTORY src/ DESTINATION include/MXADataModel REGEX .*\\.h$ ) which I think should work. So what am I doing wrong? I think that the regex must also match the directories that contain the header files. If a directory doesn't match, its files aren't processed. I overcame this issue using file(GLOB_RECURSE ...), which works quite well, despite this solution not being the most direct. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
Brandon Van Every escreveu: Do the REGEX and/or REGEX ... EXCLUDE signatures work? If so, then this is a low priority feature request. A PATTERN spares the programmer from having to learn how regexes work, but specifying these kinds of inclusions and exclusions with regexes is trivial. REGEX / REGEX ... EXCLUDE doesn't work because it should also match each subdirectory to be installed, so the most trivial REGEX .*\\.[^h] EXCLUDE doesn't do the trick. Can't imagine why it wouldn't be. You say it's easy to implement, and it's not controversial. Maybe next year :) Abraços, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
Brandon Van Every escreveu:
What version of CMake are you using? CMake 2.4.7 documentation says
plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should
work fine without an EXCLUDE
I think you've meant INSTALL(...). Documentation says:
The PATTERN and REGEX options specify a globbing pattern or regular
expression to match directories or files encountered during traversal of
an input directory.
...
Options following one of these matching expressions are applied only to
files or directories matching them. The EXCLUDE option will skip the
matched file or directory. The PERMISSIONS option overrides the
permissions setting for the matched file or directory.
So, pattern/regex are only used to specify which files you want to
exclude or set permissions. Nothing is said about only allowing matching
files to be installed, so the current behaviour is correct, albeit not
ideal.
One testcase is the following:
* tst
CMakeLists.txt
* include
* test
test.cpp
test.h
another.h
CMakeLists.txt contains:
install(DIRECTORY include DESTINATION ${CMAKE_BINARY_DIR}/usr PATTERN *.h)
After doing a cmake ./make install, we have:
-- Install configuration:
-- Installing /home/rodolfo/src/tst/usr/include
-- Installing /home/rodolfo/src/tst/usr/include/test
-- Installing /home/rodolfo/src/tst/usr/include/test/test.cpp
-- Installing /home/rodolfo/src/tst/usr/include/test/test.h
-- Installing /home/rodolfo/src/tst/usr/include/test.h
-- Installing /home/rodolfo/src/tst/usr/include/another.h
The 'test.cpp' gets copied :( And this happens with both cmake-2.4.7 and
cmake-cvs (as of 12/28/2007).
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:54 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: So, pattern/regex are only used to specify which files you want to exclude or set permissions. The docs do not say that. [PERMISSIONS permissions ...] are optional. Nothing is said about only allowing matching files to be installed, so the current behaviour is correct, albeit not ideal. No, it's bugged. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Find* and cross compiling
Hi all, I've been exercising cmake-cvs's cross-compiling capabilities and I've noticed that the way several Find* scripts work doesn't behave well with cross-compiling. Usually when doing this kind of builds (at least in linux), one have a place (for instance /usr/i686-mingw32-pc) where all binaries compiled to run on the target platform resides. When looking for installed libraries, the Find* first try to look into this prefix (/usr/i686-mingw32-pc), but it it doesn't find, they continue by looking into /usr, picking the incorrect binaries, since these are compiled to the native system. I've found those issues in FindLua*.cmake, FindFreetype.cmake and others. The reason is that they specify '/usr', '/usr/local', ... as search paths, instead of relying on the correct cmake's default. If the developers agree that this is a major blocker for cross-compiling with cmake, I could help by correcting some scripts. Just let me know. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] /MACHINE:x64
George Neill wrote:
Hi CMakers!
I am trying to compile on a 64 bit windows machine (AMD64). It seems
CMake only outputs /MACHINE:X64 for the link flags. However,
link.exe reports that flag doesn't exist. Is this a bug?
I am using,
cmake version 2.4-patch 7
cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
link.exe
Microsoft (R) Incremental Linker Version 8.00.40310.39
Copyright (C) Microsoft Corporation. All rights reserved.
options for /MACHINE: from link.exe /?
/MACHINE:{AM33|AMD64|ARM|CEE|EBC|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
MIPSR41XX|SH4|SH5|THUMB|X86}
Let me know if you need more info.
What version of the compiler do you have?
With vs 2005, which was the first one we supported 64 bit builds, I get
this:
$ link /?
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/MACHINE:{ARM|EBC|IA64|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
SH4|THUMB|X64|X86}
Exactly what steps are you taking for running cmake, and installing the
compiler?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] /MACHINE:x64
Hi Bill,
Thanks for responding.
What version of the compiler do you have?
With vs 2005, which was the first one we supported 64 bit builds, I get
this:
Windows Server 2003 SP1 Platform SDK and the Visual C++ toolkit 2003.
The following link appears to be similar to issue(s) I am having ...
http://www.planetamd64.com/lofiversion/index.php?t5878.html
$ link /?
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/MACHINE:{ARM|EBC|IA64|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
SH4|THUMB|X64|X86}
Exactly what steps are you taking for running cmake, and installing the
compiler?
cd out_of_source_build_dir
cmake -GNMake Makefiles -DCMAKE_BUILD_TYPE=Release ..\src
I will have to get back to you on the steps to install the compiler
(because I didn't install it). But I can tell you a simple hello
world! c program compiles and runs just fine when compiled by hand.
I was able to get past the /machine:x64 issue, by changing
Windows-cl.cmake. But now I am running in to RTC error unresolved
external symbol _RTC_Shutdown when running cmake which I think is
caused by (a previous post of mine)
http://www.cmake.org/pipermail/cmake/2007-December/018866.html.
TIA,
George.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
