Re: Language module support modified

----- Original Message ----- 
From: "Bram Moolenaar" <[email protected]>

> Please correct and extend the docs in ref-modules when needed.

Yes, I will.

> That means it's better to leave $DDEFINE out, right?

IMO, yes.

>
> >     DINCLUDE is for including stuff, but they are called imports in D
> >     (like Java).  Should DIMPORT be the name, perhaps?
>
> Avoiding confusion between $INCLUDE and $DINCLUDE is good.  Using
> $DIMPORT sounds logical to me.

Great minds, etc :)

>
> >     DVERSION would be for the compiler arguments -version=level and
> >     -version=ident. Several idents and a level can be used to compile
> >     in or out parts of the source. It usually looks like this:
>
> OK, thus it's a language-related argument that has a specific syntax.
> It's good to keep these separate from $DFLAGS, so that they can be
> translated if there is a D compiler that uses /v:ident instead of
> -version=indent, for example.

Yep.

>
> >     DDEBUG was proposed by me because it in addition to setting the
flags
> >         -g [symbolic debug info] and -gt [trace profiling hooks], it
> >         is also possible to compile in (and out) debug code in much
> >         the same way as with -version.
> >         The main difference as I see it, is that debug code don't HAVE
> >         to be qualified by an identifier or level. Also, it will
> >         always be compiled out when the release flag is used (probably
> >         as a DFLAG).  Compiling/excluding unittests is also a part of
> >         this, as is contracts.
>
> It only makes sense to add arguments to a specific variable if we can do
> something with it.  The use of $DEBUG is that the tool can check the
> value and then add the appropriate argument to the compiler.  This only
> works for generic settings, in this case debugging on/off.  If the
> compiler has specific arguments that other compilers are unlikely to
> have, these can be added to $DFLAGS.  It's then up to the recipe writer
> to use the right arguments, since Aap can't offer him a generic way of
> doing it.  This means the recipe isn't portable to another compiler.
> This would require a configure check.

I understand you, but I don't think I explained myself good enough.
Debug constructs are a part of the language in the same way as version
constructs are. Thus a $DDEBUG variable should be present IMHO.

I also agree that the recipe writer must know if he use other compiler
specific flags. :usetool and :conf should be a good help then.

>
> The same applies to optimizing flags.
>
> >     OPTIMIZE might make sense as it is now. The current version of the
> >     compiler takes only one optimize flag, -O, but it would probably
> >     be ignorant not to expect more.
> >
> > > - Each tool and/or module uses the standard $DEBUG and $OPTIMIZE
> > >   variables.  These need to be converted to arguments that the
specific
> > >   compiler accepts.
>
> You could probably use something like:
>
> @if _no.OPTIMIZE and int(_no.OPTIMIZE) > 0:
>    oarg = -O
> @else:
>    oarg =
>
> :sys $DMD ... $oarg ...

Just what I was thinking. I guess this must be present in the dmd.py too.

Lars Ivar Igesund




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf