[CMake] maximum length of a list

2010-06-27 Thread Hicham Mouline
hello I assign the list of all directories the names of which starts with a pattern like pattern_ to a cmake variable which I then pass as a preprocessor macro: FILE(GLOB MYPROJECT_LIST_SYSTEMS RELATIVE ${CMAKE_SOURCE_DIR} system_*) MYPROJECT_LIST_SYSTEMS is then a cmake list, a string

Re: [CMake] maximum length of a list

2010-06-27 Thread David Cole
On Sun, Jun 27, 2010 at 11:05 AM, Hicham Mouline hic...@mouline.org wrote: hello I assign the list of all directories the names of which starts with a pattern like pattern_ to a cmake variable which I then pass as a preprocessor macro: FILE(GLOB MYPROJECT_LIST_SYSTEMS RELATIVE

Re: [CMake] An observation about CTest

2010-06-27 Thread Convey, Christian J CIV NUWC NWPT
I don't expect a lot of support for what I'm about to say, but I think it's perhaps worth saying anyway... It seems like CMake's and CTest's have outgrown their scripting languages. As far as I can tell, all CMake/CTest variables are either macro formal parameters, or variables in a single

Re: [CMake] An observation about CTest

2010-06-27 Thread Eric Noulard
2010/6/27 Convey, Christian J CIV NUWC NWPT christian.con...@navy.mil: I don't expect a lot of support for what I'm about to say, but I think it's perhaps worth saying anyway... It seems like CMake's and CTest's have outgrown their scripting languages. As far as I can tell, all CMake/CTest

Re: [CMake] An observation about CTest

2010-06-27 Thread Convey, Christian J CIV NUWC NWPT
Hi Eric, Thanks for all those details. I wasn't aware that CMake drew a distinction between macros and functions. I'll try to have a look at the ML archives. - Christian -Original Message- From: Eric Noulard [mailto:eric.noul...@gmail.com] Sent: Sunday, June 27, 2010 16:42 To:

Re: [CMake] An observation about CTest

2010-06-27 Thread Alan W. Irwin
Your remarks focus on old-fashioned macros so it is possible you are not aware of functions? As far as I know, most or all macros can be replaced by functions which do have the nice property of not polluting the global namespace. So newly developed build systems should use functions wherever

Re: [CMake] An observation about CTest

2010-06-27 Thread Convey, Christian J CIV NUWC NWPT
Hi Alan, Thanks, I wasn't aware of the shift towards the use of FUNCTIONs. Because of the developers I need to support, I've been mosting working with CMake 2.6. I didn't realize that this was one of the things 2.8 brought to the table. - Christian -Original Message- From: Alan W.

Re: [CMake] An observation about CTest

2010-06-27 Thread Chris Hillery
CMake 2.6 supports functions as well. CMake 2.4 doesn't, however. I think your initial point is good one, though. There is still a significant dependence on global variables in CMake and especially CTest. Additionally, as has been discussed, there's not even a completely consistent naming

[CMake] No +DD64 compiler option for HP-UX on IA64

2010-06-27 Thread Won Kim
Hello, I've been trying to set up CMake on different build machines. Everything went perfectly on Linux machines (32/64bit), however, CMake gave me the following error message during configuration on HP IA64. -- The C compiler identification is GNU -- Check for working C compiler:

[CMake] Generating dependencies with gcc -M

2010-06-27 Thread Tom Birch
CMake's dependency scanner uses its own parser to scan for #include directives, and then builds up the dependency tree this way. I know it's possible to rig up an invocation of gcc -M to generate the correct dependencies, and then feed this into the OBJECT_DEPENDS property of source files, but

Re: [CMake] An observation about CTest

2010-06-27 Thread Andreas Mohr
Hello, On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote: Your remarks focus on old-fashioned macros so it is possible you are not aware of functions? As far as I know, most or all macros can be replaced by functions which do have the nice property of not polluting the