Re: Language module support modified

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

> I think you need to give a bit more explanation about using $DVERSION.

I think I need to explain other things more, too. Look further down.

>
> > Except for the DLINKFLAGS, all of the arguments can in theory be put
> > into the DFLAGS variable, but the rationale is to make it easier for the
> > user to see what goes where and that the D language has the possibility
> > to specify lots of debug and version flags that decide which parts of
the
> > code to compile (a preprocessor replacement).
> >
> > These changes can be found in d.diff and dmd.diff
>
> This makes me wonder how we should use the optional arguments for a
> compiler other than the C or C++ compiler.
>
> For C we use $CFLAGS, $DEFINE, $INCLUDE, $DEBUG and $OPTIMIZE.  The idea
> is that all C compilers use these and convert them from the standard
> syntax (what is used on Unix) to whatever the compiler accepts.
>
> Since the D language appears to use similar arguments, should we use the
> same variables, or with a "D" prepended, like what Lars is using now?
>
> I think we should at least be consistent, thus either use the C flags
> for D as well, or only use D specific flags.  That means $INCLUDE should
> not be used for D as it is now.

Good point. I just kept using it, since dmd use the same syntax for include
paths.

>
> On the other hand, $DEBUG and $OPTIMIZE are not arguments, but generic
> Aap settings.  $DEBUG can be set to "yes".  $OPTIMIZE is a number from
> zero to nine.  For C the cflags_normal() function is used to turn them
> into arguments for the C compiler.
>
> Let me do a proposal:
>
> - For each language we have a set of variables similar to $CFLAGS,
>   $DEFINE and $INCLUDE, but specific for that langauge.  This is
>   logical, since using the values given to the C compiler would probably
>   not work for another language.
>   For D we have $DFLAGS, $DDEFINE and $DINCLUDE.  And as an extra
>   $DVERSION, which is apparently specific for D.

Ok;
    DFLAGS is ok,
    DDEFINE not very useful, except if people start using external
preprocessors
        for D (which the language designer wants to avoid)
    DINCLUDE is for including stuff, but they are called imports in D (like
Java).
        Should DIMPORT be the name, perhaps?
    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:

version (bar) {
    ....
    ....
}
version (foo) {
    ....
    ....
}

    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.

    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.

    (As an aside on OPTIMIZE; the Open Watcom compiler have very many
        optimizeflags that I don't think fit into the 0-9 scheme.

>
> $DEBUG and $OPTIMIZE could be used as well, if you know what dmd
> areguments are used for this.

As mentioned above; this might work well for OPTIMIZE. For DEBUG,
I think there are too many options.

Lars Ivar Igesund



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