[CMake] CMake memory exhaustion

Alan W. Irwin irwin at beluga.phys.uvic.ca
Thu Jul 19 16:08:45 EDT 2007


On 2007-07-19 14:58-0400 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>> The (truncated) error message I am getting is as follows:
>> 
>> make package_source
>> 
>> Run CPack packaging tool for source...
>> /home/software/cmake/install/bin/cpack --config
>> /home/irwin/cdburn1/interior_eos
>> /SFHEAD/build_dir/CPackSourceConfig.cmake
>> CMake Error: Syntax error in cmake code at
>> /home/irwin/cdburn1/interior_eos/SFHEAD/build_dir/CPackSourceConfig.cmake:32: 
>> memory exhausted (4376), when parsing string
>> "[...]"
>> CPack Error: CPack project name not specified
>> 
>> Note [...] stands for a _long_ (something like 3000 characters) semi-colon
>> separated string (i.e., a list).
>> 
>> IMPORTANT: I am under some deadline pressure so I would appreciate it if
>> somebody would quickly answer the following question: Where in the CMake
>> source code can I set an internal buffer size to a larger value so I don't
>> get the above memory exhausted message?  From evidence (see below) it
>> appears the buffer needs to be roughly a factor of 10 larger for my needs.
>> 
>> The above error message was generated with cmake version 2.4-patch 7 
>> RC-11.
>> I doubt very much that 2.4.7 will resolve this problem, but I will try 
>> that
>> later this afternoon.  I am posting this memory exhausted report now 
>> rather
>> than waiting until I try 2.4.7 because I am hoping for a quick reply to 
>> the
>> above question on how to increase the buffer size.
>> 
>> To those interested in some background about why I need more buffer space, 
>> I
>> am using the usual
>> 
>> set(CPACK_SOURCE_IGNORE_FILES
>> "regex1"
>> ...
>> "regexn"
>> )
> Sounds like a problem with the lex parser stuff.   Can you try something like 
> this:
>
> set(CPACK_SOURCE_IGNORE_FILES "regex1".... "regex30")
> set(CPACK_SOURCE_IGNORE_FILES ${CPACK_SOURCE_IGNORE_FILES} "regex31" .... 
> "regex100")
> set(...)
>
> You get the idea.   I think the problem might be the really long string.  And 
> if you break it up into
> several set calls it might get around the limitation.

Thanks for your quick reply, Bill.  I have just confirmed the memory
exhaustion problem occurs also for 2.4.7, and all other tests I report below
are for that version of cmake.

The general problem is whatever string manipulations I do in my top-level
CMakeLists.txt, the result is copied to CPackSourceConfig.cmake in the build
tree in the long string form, i.e.

set(CPACK_SOURCE_IGNORE_FILES "regex1;regex2;...;regex300")
(or regex30 for the successful tests and regex60 for additional unsuccessful
ones).

Just now I have edited that generated file and made a "transformed" copy of
the CMakeLists.txt separated strings form  e.g.,

set(CPACK_IGNORE_FILES "regex1" "regex2" ... "regex300")
set(CPACK_SOURCE_IGNORE_FILES "regex1" "regex2" ... "regex300")

The transformation I had to do was to change all occurrences of \\\\ in
the CMakeLists.txt form of the regexes to \\ (which appears to happen
when CPackSourceConfig.cmake is generated automatically).

So with this workaround, the source distribution tarball is generated
without any error messages, but the tarball is big so it appears something
systematic might be wrong with my regex's. Perhaps the transformation of
\\\\ to \\ is not needed when it is in separated string form rather than
list form?) Anyhow, I assume with a bit more effort I can get the regex's to
actually work with this approach which should allow me to meet my deadline.

However, this is a really clumsy workaround so, Bill, can you recommend a
2.4.7 fix I can test?

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
__________________________


More information about the CMake mailing list