[CMake] Compile flag issues and VS Express

Glenn Coombs glenn.coombs at gmail.com
Thu Feb 2 18:54:15 EST 2012


I think 10M is an insanely large default stack size.  It just encourages
people to create int foo[100][100][100] on the stack instead of learning
how to use malloc or new.  When creating non-cmake Visual Studio projects
the default stack size is way more sensible.  I can't see any reason to
default to 10M for cmake generated projects and would love to see this
default removed.  As it is I have to override it for all my projects.

--
Glenn

On 1 February 2012 10:14, Yuri Timenkov <yuri at timenkov.ru> wrote:

> I can assume that 10M stack is reasonable for C code, where it's usual to
> allocate temporary buffers on stack (in C++ it's easier to use heap, e.g.
> using std::vector).
>
> Bad thing is - impact of this flag is detected only at run time. If with
> /Zm your code just won't compile, with /STACK everything compiles and links
> perfectly, works fine in simple cases, but you'll receive OOM under load
> (in C, when stack will be over).
> That's why I didn't insist on changing behavior when found this bug 3
> years ago.
>
>
> On Tue, Jan 31, 2012 at 8:02 PM, Glenn Coombs <glenn.coombs at gmail.com>wrote:
>
>> On a related note:
>>
>> http://www.gccxml.org/Bug/view.php?id=12437
>>
>> can you check if ITK and VTK build fine without the large stack size
>> argument (/STACK:10000000) as well ?
>>
>> --
>> Glenn
>>
>>
>> On 30 January 2012 15:58, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>
>>> ITK and VTK both build fine if I remove the /Zm1000 flag.
>>>
>>> On Mon, Jan 30, 2012 at 10:44 AM, Bill Hoffman <bill.hoffman at kitware.com>
>>> wrote:
>>> > On 1/28/2012 10:51 AM, David Cole wrote:
>>> >>
>>> >> Seems reasonable. Is anybody worried that changing the default values
>>> >> of these flags would have a negative impact on any projects out there?
>>> >> (i.e. is it likely that anybody relies on these flags being present
>>> >> and that would somehow break their build without them...? I don't
>>> >> think it's likely, but I'm willing to discuss before making a change
>>> >> in CMake)
>>> >
>>> >
>>> > They were originally put in for VTK/ITK.  They would be the projects
>>> to try.
>>> >
>>> > -Bill
>>> >
>>> >
>>> > --
>>> >
>>> > 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
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>> --
>>>
>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120202/693d0330/attachment-0001.htm>


More information about the CMake mailing list