Re: resurrecting automatic dependencies

[Tom Tromey <tromey at redhat dot com>]

Tom> There may be more missing dependencies.  Please try out this branch if
Tom> you would.  You can report bugs to me, just send the build log.

I tried -j33 on a bigger machine and found a problem with Go.

The dependency patch uses the language Makefile conventions to add some
order-only dependencies to ensure that generated files are made early
enough (this code is actually already in gcc, but it has some latent
bugs).  In particular it uses the $(lang)_OBJS variable (via
ALL_HOST_OBJS).

However, Go does not set go_OBJS, so a sufficiently large -j setting
will cause a build failure, as a Go file is compiled before a generated
header.

Fixing this is simple enough in go/Make-lang.in; but this also has the
side effect of defining IN_GCC_FRONT_END for the various Go
compilations:

$(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += -DIN_GCC_FRONTEND))

... which causes build failures for go-backend.c (uses rtl.h) and
go-lang.c (uses except.h), since with this defined, certain headers are
prohibited.


A short term solution is to keep Go using explicit dependencies.

For a long term solution ... well, I'm CCing Ian.

The except.h doesn't seem to be needed.  At least, I removed the include
and go-lang.c still compiled.  The go-backend.c problem looks harder,
though.  Thoughts?

Tom