[CMake] CMake memory exhaustion

[Alan W. Irwin]

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"
)

pattern in the top-level CMakeLists.txt file to use various regex's to
ignore certain files in the source tree. However, there are something like
300 of these regex's because I have a rather dirty source tree with about 1
gigabyte of generated files (mostly scientific data files that are generated
as part of the documentation build) in it.

The source tree is under svn control so I already have set the svn:ignore
property (similar to .cvsignore for those of you who are more familiar with
CVS) to ignore the generated files in the various documentation
subdirectories, and I have a python script (see
http://freeeos.svn.sourceforge.net/viewvc/freeeos/trunk/ignore.py?view=log)
to transform those properties into the regex syntax understood by
CPACK_SOURCE_IGNORE_FILES).

I have used the above CPACK_SOURCE_IGNORE_FILES and various subsets of the
regex lists and found the following definitive evidence that it must be
buffer overflow that is the problem and not something wrong
with the regex's themselves.  If I process just a 30-element subset
of the 300 regex's all is well with the source package build (except for a huge
result).  Similarly I get success with a different 30-element subset
of the 300 regex's.  But if I combine the two into a 60-element subset, then
I get the above memory exhausted message just as when I process the full 300
regex's.  So it appears I basically need some CMake internal buffer increased
by a factor of 10 in size.  The question is which buffer, and how to increase
its size?

N.B. I am well aware that I could put all the documentation builds under
CMake control and use a separate build tree to keep the source tree clean.
But the current documentation build is under the control of a number of
different Makefiles, and I don't want to have to go to all the work of
transforming that Makefile-based documentation build system to the
equivalent CMake one just to work around a limitation in the size for one of
the CMake internal buffers.  Also, in any case it appears the current
effective limitation on the number of regex's for CPACK_SOURCE_IGNORE_FILES
is somewhere between 30 and 60, and that is way too low.

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
__________________________