Date:	Thu, 10 Nov 94 06:07:00 JST
From:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Extending the djgpp.env file [was: Real-mode gcc renamed doesn't work]

This is a sort of rambling discussion of some possibilities for the
DJGPP.ENV file.  Now that I've written, it's not clear that
Hans-Bernhard's solution isn't the best way to go, but since I've
already written it, I'm going to send it with that caveat.
    The motivation for me is that I find working with the DOS
environment a real pain in the neck.  Usually with Unix I play with a
variable for a session or two, find an appropriate setting, put it in
an appropriate .rc file and forget it.  But with DOS I'm *always*
tweaking paths, aliases, and environment variables, especially to work
around compiler bugs or multiple configurations.  I've got an
env_vars.bat file that I call from autoexec.bat; if I uncommented
everything in it, I'd have an environment of about 3KB!  Add that to
my 4DOS alias file and you've got a 5KB environment.  In Unix, it's
"so what, that's what the environment is for".  But in DOS it's costly
enough to make one think about putting it in a file to be read at run
time....
    Also, I often find that I'm too lazy (or senile) to edit
env_vars.bat *and* call it to change the environment.  But if I
thought of the file as the environment, instead of as an
initialization file, it would be a lot more natural to edit that and
be done with it.  (And Emacs supports a lot more editing commands than
SET does ;-)

   > The problem is that the real-mode gcc won't read the environment file
   > new to djgpp 1.12 (djgpp.env) so you have to set those environment
   > variables in the master environment.

   Well, it *does* read it, but it looks for a paragraph beginning with a
   line like this: [gcc-rm].

   So: copy that section of djgpp.env and change the [gcc] line to
   [gcc-rm], and it *will* work! (at least it did for me)

   Hans-Bernhard

There's been a bit of traffic recently about people using multiple
instances of various GO32 software:  gcc-rm *and* gcc, ld 2.4 *and* ld
2.2, cc1plus 2.6.0 *and* cc1plus 2.5.x, and so on.  For people who
have reason to use multiple versions regularly, perhaps even in the
same build, could we extend the syntax of the DJGPP.ENV file to allow
multiple programs to share the same section?  I can think of a number
of syntaxes that might work:
(1) disallow null program-specific sections.  Then

        [gcc]

        [gcc-rm]
        foo=bar

        [gcc-nantoka]
        foo=baz

would be interpreted

        [gcc]
        foo=bar

        [gcc-rm]
        foo=bar

        [gcc-nantoka]
        foo=baz

(2) Have sections terminated by blank lines.  Then the above would be
    interpreted as a null section for gcc, but 

        [gcc]
        [gcc-rm]
        foo=bar

        [gcc-nantoka]
        foo=baz

would set the section for gcc to the same as that for gcc-rm.
(3) use the lexical syntax "[gcc, gcc-rm]" for mutiple program section
    headers.
(4) use the lexical syntax "[gcc] [gcc-rm]" (all on one line).
(5) Independently of the above possibilities, do we permit (now or in
    the future) multiple sections for a given program so that

        [gcc, gcc-rm]
        foo=bar

        [gcc]
        baz=blap

        [gcc-rm]
        spock=bones

    means

        [gcc]
        foo=bar
        baz=blap

        [gcc-rm]
        foo=bar
        spock=bones

    We may not want the environment file possibilities to be as
baroque as Windwoes .INI files, but then again, it's not clear to me
that this would cost that much (except somebody's time in programming
it---and it may not be worth that).  In fact, if it's not too costly,
Windwoes .INI syntax might not be a bad "standard" to be compatible
with.  (Or upwardly compatible with.)
    On the other hand, in Windwoes .INI files a given program will be
affected by multiple sections, because Windwoes takes care of making
sure that video drivers and 386 enhanced drivers get loaded for the
program.  Do we want this?  In particular, the current specification
has the GO32 variable read before the DJGPP.ENV file.  Is there any
reason not to allow the GO32 variable to be placed in the DJGPP.ENV
file?  (Then it would be nice to have instead of DJGPP pointing to the
environment file, GO32 would point to the environment file, and the
GO32 section would become GO32-EXTENDER in the file.  But this would
either break the current GO32 variable, or require that GO32 check
which semantics was intended, a literal string of specifications or a
file pointer.  I guess this could be fixed pretty easily by using the
response-file @-syntax for file pointers in the environment variable.)

+-----------------------------------------------------------------------+
|                           Stephen Turnbull                            |
|     University of Tsukuba, Institute of Socio-Economic Planning       |
|          Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN            |
|        Phone:  +81 (298) 53-5091     Fax:  +81 (298) 55-3849          |
|               Email:  turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp                 |
|                                                                       |
|                Founder and CEO, Skinny Boy Associates                 |
|               Mechanism Design and Social Engineering                 |
| REAL solutions to REAL problems of REAL people in REAL time!  REALLY. |
|                      Phone:  +81 (298) 56-2703                        |
+-----------------------------------------------------------------------+

- Raw text -