Pretzel logic in cmd/cc, cmd/?a and cmd/?c

[Lucio De Re]

It all starts with a comment in src/cmd/8a/a.y: "if we don't, bison will, and a.h re-#defines getc"

The Plan 9 native toolchain objects to the inclusion of <stdio.h> on the grounds that <stdio.h> is not self-sufficient as it is in the Posix environments.  So the easy solution is to figure out a way to drop <stdio.h> conditionally.  I haven't yet figured out a way to do this.

Instead, I tried to get to the bottom of the problem, applying the Plan 9 formula that says that header files should preferably not include other header files, but should be documented insofar as their prerequisites are concerned.

Suffice it to say that it is impossible to describe the contortions one needs to go through just to understand the interactions between 8a/a.y, 8a/a.h, 8a/lex.c, cc/cc.h, cc/lexbody, cc/lex.c, cc/macbody and cc/mac.c.

So, this is me throwing down the gauntlet: this stuff has driven me away from porting the Go toolchain to Plan 9 before, this time I intend to get it fixed.  And fix the Plan 9 toolchain in the process.  It will mean extensive re-arrangements of the contents of src/cmd/?a, src/cmd/cc, src/cmd/?c (but hopefully not src/cmd/gc or src/cmd/8g).  If there are any strong views on this issue, now would be a great time to speak up.

My immediate bugbears are (a) alloc()/allocn() and their mirrors mal()/remal(): there were three different implementations last time I looked at this issue, with no hints why one should be chosen in preference to another; (b) is there a better way to define the lexical analyser than to #include various combinations of "lexbody" and "macbody" in various arbitrary modules?

I'm expecting that I'm not the first person to be confronted by this labyrinth, please feel free to share any thoughts, opinions and code with me.

Lucio.

[Russ Cox]

the changes you have been sending us, with minimal tweaks
needed to build on plan 9, are great. please keep sending those.
please do not send us change lists rearranging the compiler sources.

1. we've had this discussion before.
2. the build process is actually unchanged from plan 9.
3. not understanding the build process is not
justification for changing it.
4. it's not worth the time or effort.

if you have specific questions (your email has none), then ask,
and we'll be happy to answer them. i answered your <stdio.h>
complaint in the other thread.

also, plan9front claims to include a working go compiler.
what did they do?

russ

[Taru Karttunen]

On Mon, 20 Jun 2011 11:42:19 -0400, Russ Cox <r...@golang.org> wrote:
> also, plan9front claims to include a working go compiler.
> what did they do?

Did some hacking.

source: http://pkg.violetti.org/src/go-2011.05.10.tbz
binary: http://pkg.violetti.org/386/go-2011.05.10.tbz

- Taru Karttunen