[CMake] maximum length of a list
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 with semicolon
separators.
What is the maximum number of entries in the list that cmake handles?
Or what is the maximum length of a cmake string?
Regards,
___
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] maximum length of a list
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 ${CMAKE_SOURCE_DIR} system_*)
MYPROJECT_LIST_SYSTEMS is then a cmake list, a string with semicolon
separators.
What is the maximum number of entries in the list that cmake handles?
Or what is the maximum length of a cmake string?
In theory, it should be around 2G for 32-bit build of CMake.
In practice, I bet you'll run into the beginnings of performance issues if
you start to have strings that are 10s or 100s of megabytes large.
There's no hard-coded or stack-based limits in CMake that I'm aware of -- it
should be simply based on how much memory CMake can allocate... so:
hopefully, larger than anything you can throw at it... :-)
HTH,
David
Regards,
___
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] An observation about CTest
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 global namespace. I think one consequence of this is that macro invocations make their contributions primarily by modifying variables in the global namespace. As people discovered in the 1970's and 1980's, the confusion caused by this approach (global variables) can be so extensive that it's worthwhile to change coding pracices (structured programming, etc.), and possibly to improve the base language as well. It the CMake scripting language wouldn't be allowed to change, then I'd want to consider a change to CMake coding style: Any macro invocation that's intended to update global state (for example, INCLUDE_DIRECTORIES(foo)) should only be allowed to modify global-namespace variables that are explicitly named as parameters to the macro call. For example: INCLUDE_DIRECTORIES(foo, MY_DIRECTORIES_LIST). But even better would be enhancing the CMake scripting language to support local variables in macros, and possible package-scoped variables as well. This clarifies the intended interface that certain macro packages are intended to provide, because variables intended as implementation details would be in a namespace inaccessible to the script that invokes those macros. Another possiblity, which I'm sure has been considered, would be to stop having CMake and CTest provide their own scripting languages, and instead make them be libraries in some other, more advanced scripting language like Python. Anyway, that's just my two cents as someone who's been casually using CMake for the past two or three years. - Christian Hi all, I tend to agree to this observation in general about CMake too. I had to do a lot of reading and experimentation to make it do what I wanted, even though at the end of the day, the resulting CMakeList.txt file is very simple. I do understand why this is so. As can be seen by the type of requests on this list and your responses to them, Cmake is supporting a LOT of different types of projects and needs. So while it won't be possible to reduce the number of commands and variables, it would help to have better documentation -- with examples for each command and variable, examples for typical stuff people need, etc. I had to struggle even to do simple things like specifying custom compiler and linker flags for Visual Studio and GCC. Thanks and best regards - Alok smime.p7s Description: S/MIME cryptographic 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] An observation about CTest
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 variables are either macro formal parameters, or variables in a single global namespace. I think one consequence of this is that macro invocations make their contributions primarily by modifying variables in the global namespace. As people discovered in the 1970's and 1980's, the confusion caused by this approach (global variables) can be so extensive that it's worthwhile to change coding pracices (structured programming, etc.), and possibly to improve the base language as well. I think you should dive into the Mailing List archive because there have been several valuable discussion about CMake evolution including the replacement/extension of CMake scripting language with full language like Lua or Python. But even better would be enhancing the CMake scripting language to support local variables in macros, and possible package-scoped variables as well. This clarifies the intended interface that certain macro packages are intended to provide, because variables intended as implementation details would be in a namespace inaccessible to the script that invokes those macros. CMake is offering scope from a parent/child point of view including setting variable for your parent with set( PARENT_SCOPE) this was indeed provided after lengthly ML discussion. Concerning local variables you should have a look at the difference between a MACRO and a FUNCTION this may already gives you part of what you want. Then as far as I can tell CMake scripting is no-where near a must not evolve language many improvement has been put in since I began to use CMake 2.2.x (can't remember X) even the introduction of POLICY which each backward compatibility. So I think you may not hope to have ALL what you require in CMake after a message on this ML be you will certainly have feedback and may be new feature if there is a consensus and some proof of concept patch provided. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] An observation about CTest
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: Convey, Christian J CIV NUWC NWPT Cc: alokgo...@hotmail.com; cmake@cmake.org Subject: Re: [CMake] An observation about CTest 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 variables are either macro formal parameters, or variables in a single global namespace. I think one consequence of this is that macro invocations make their contributions primarily by modifying variables in the global namespace. As people discovered in the 1970's and 1980's, the confusion caused by this approach (global variables) can be so extensive that it's worthwhile to change coding pracices (structured programming, etc.), and possibly to improve the base language as well. I think you should dive into the Mailing List archive because there have been several valuable discussion about CMake evolution including the replacement/extension of CMake scripting language with full language like Lua or Python. But even better would be enhancing the CMake scripting language to support local variables in macros, and possible package-scoped variables as well. This clarifies the intended interface that certain macro packages are intended to provide, because variables intended as implementation details would be in a namespace inaccessible to the script that invokes those macros. CMake is offering scope from a parent/child point of view including setting variable for your parent with set( PARENT_SCOPE) this was indeed provided after lengthly ML discussion. Concerning local variables you should have a look at the difference between a MACRO and a FUNCTION this may already gives you part of what you want. Then as far as I can tell CMake scripting is no-where near a must not evolve language many improvement has been put in since I began to use CMake 2.2.x (can't remember X) even the introduction of POLICY which each backward compatibility. So I think you may not hope to have ALL what you require in CMake after a message on this ML be you will certainly have feedback and may be new feature if there is a consensus and some proof of concept patch provided. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org smime.p7s Description: S/MIME cryptographic 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] An observation about CTest
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 possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. Here are some rough counts of functions and macros actually contained in 2.8.x: ir...@raven grep -i function cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 263 ir...@raven grep -i macro cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 337 Those numbers should be divided by roughly a factor of two (because of ENDFUNCTION and ENDMACRO) to get approximate counts of functions and macros. Clearly, the replacement of macros by functions is well on its way for 2.8.x, but the process is still far from completed. Once it is complete, however, the global namespace will be much less polluted. Another namespace remark is that subdirectory variables do not pollute the global namespace of their parent directories. So the global namespace pollution issue is not as bad as you have outlined and because of functions is steadily improving. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] An observation about CTest
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. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Sunday, June 27, 2010 16:49 To: Convey, Christian J CIV NUWC NWPT Cc: alokgo...@hotmail.com; cmake@cmake.org Subject: Re: [CMake] An observation about CTest 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 possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. Here are some rough counts of functions and macros actually contained in 2.8.x: ir...@raven grep -i function cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 263 ir...@raven grep -i macro cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 337 Those numbers should be divided by roughly a factor of two (because of ENDFUNCTION and ENDMACRO) to get approximate counts of functions and macros. Clearly, the replacement of macros by functions is well on its way for 2.8.x, but the process is still far from completed. Once it is complete, however, the global namespace will be much less polluted. Another namespace remark is that subdirectory variables do not pollute the global namespace of their parent directories. So the global namespace pollution issue is not as bad as you have outlined and because of functions is steadily improving. Alan smime.p7s Description: S/MIME cryptographic 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] An observation about CTest
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 convention for those variables, nor is the documentation anything like good enough at covering everything. It really is a significant barrier to entry. It's unfortunate, but I don't know that it can be fixed, really. CMake puts a great deal of effort into backwards compatibility, and changing away from global variables or at least having a massive rename-fest would be difficult to achieve with anything like compatibility. Perhaps CMake 3.0 could have a clean break... Ceej aka Chris Hillery On Sun, Jun 27, 2010 at 1:52 PM, Convey, Christian J CIV NUWC NWPT christian.con...@navy.mil wrote: 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. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Sunday, June 27, 2010 16:49 To: Convey, Christian J CIV NUWC NWPT Cc: alokgo...@hotmail.com; cmake@cmake.org Subject: Re: [CMake] An observation about CTest 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 possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. Here are some rough counts of functions and macros actually contained in 2.8.x: ir...@raven grep -i function cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 263 ir...@raven grep -i macro cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l 337 Those numbers should be divided by roughly a factor of two (because of ENDFUNCTION and ENDMACRO) to get approximate counts of functions and macros. Clearly, the replacement of macros by functions is well on its way for 2.8.x, but the process is still far from completed. Once it is complete, however, the global namespace will be much less polluted. Another namespace remark is that subdirectory variables do not pollute the global namespace of their parent directories. So the global namespace pollution issue is not as bad as you have outlined and because of functions is steadily improving. Alan ___ 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
[CMake] No +DD64 compiler option for HP-UX on IA64
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: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- broken CMake Error at .../cmake-2.8.1-HP-UX-9000_785/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler /usr/local/bin/gcc is not able to compile a simple test program. It fails with the following output: Change Dir: /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp Run Build Command:/usr/local/bin/gmake cmTryCompileExec/fast /usr/local/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp' /data5/obmtp4/cmake-2.8.1-HP-UX-9000_785/bin/cmake -E cmake_progress_report /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o /usr/local/bin/gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec /data5/obmtp4/cmake-2.8.1-HP-UX-9000_785/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /usr/local/bin/gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec -Wl,+s,-E,+nodefaultrpath -Wl,+b/usr/lib * ld: Can't find library or mismatched ABI for -lc* Fatal error. So, I added the following two lines in HP-UX.cmake file to solve the problem: SET(CMAKE_C_COMPILER /usr/bin/cc) == Replace C compiler SET(CMAKE_C_FLAGS +DD64)== Added +DD64 compiler option for IA64. After inserting these lines, CMake could compile the sample C source file. To compare with other HP machine I tried the same in HP RISC machine, and it compiled fine without those lines. Is there anything that I need to set up before compiling on HP IA64 machine? Also, I wonder why CMake would not add +DD64 compile option automatically. If possible, I would prefer the way that CMake add necessary compile options by itself. Thank you very much, Won ___ 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] Generating dependencies with gcc -M
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 that means that dependency generation would happen when running 'cmake .', not 'make'. I guess the bigger question here is: why doesn't cmake use gcc -M internally when it's available? It's vastly superior to any homegrown parser, so why not use it? Tom ___ 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] An observation about CTest
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 global namespace. So newly developed build systems should use functions wherever possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. That's all fine and dandy (and you've written some nice prose about it :), but I've just been reading man cmakecommands of Debian cmake 2.8.1-5(!) from top to bottom and bottom to top, and nowhere does it mention _any_ underlying difference between macros and functions. Not even I knew about this difference, despite having almost a month-full of rather very internal CMake experience (Google searches in the couple hundreds, vcproj2cmake adaptation of a _large_ project etc.). Suggestion for the sake of world peace: I'll submit a patch for that man page, ok? :) Andreas Mohr ___ 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
