[Vm-dev] '-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko siguctua at gmail.com
Wed Apr 13 18:06:58 UTC 2011

On 13 April 2011 19:13, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> I've just commited the fix, but not the comment ;)
> Seriously, I don't know how we can document this kind of things.
> Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
> doesn't make sense because they are aprox. 12 implementaions...I don't want
> to copy paste to all of them. Only in one? it doesn't make sense because
> people won't see it. So..how we document this kind of things?  I have no
> idea.
> The same with class comments. There are so many classes that copy pasting or
> documenting only one doesn't make sense.

The root class is enough.
A subclasses should just say something like 'i am special for
___that__ and do things differently because i want __that__'.

> The only thing I though is doing something like this:
> compilerFlagsRelease
>     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
> '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
> '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
> '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
> '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
>>>debugVMFlagEnable: boolean
> "THIS flag is blagh...blh..."
> ^ '-DDEBUGVM=', boolean asNumber asString
> or something like that...

This knowledge is important. It of course a question where to put that,
but that's exactly why i didn't wanted to use autoconf to generate
config.h file, which contains like 50 various flags,
without any clues, where these flags being used, and in what
situations they should be turned on or off..

So, later we could step over every flag and properly document them,
and like that, for people who will come later, we will have an idea
what are need to deal with and why.

> cheers
> Mariano

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list