This is the mail archive of the
mailing list for the GCC project.
RE: Ada and bad configury architecture.
- From: "Gary Funck" <gary at intrepid dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Tue, 26 Apr 2005 16:30:34 -0700
- Subject: RE: Ada and bad configury architecture.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of
> Nathanael Nerode
> Sent: Monday, April 25, 2005 8:47 PM
> Actually, I was going to try to convince y'all to allow the *configury*
> to be put in the *configure* files. All of it. The current scheme of
> stuffing the configury in the Makefile, although I know the Ada
> maintainers like it, is just trouble, and is fundamentally the source of
> most or all of the endless Ada cross-build problems.
We implement an experimental dialect of C, called UPC, which targets
SIMD class machines. One of the changes between 3.3 and 3.4 that
have caused us the most grief is the decision to defer per-language
configuration to the make step. This means that the dialect-specific
configuration runs after gcc configuration, and we can no longer, for
example overlay (or add to) the basic configuration. As an example,
we need to introduce dialect-specific runtime start and end object
files (serving a similar function to crtbegin.o and crtend.o) but the
common start and end files are now built well before the UPC language
files are even configured. Thus, there is no mechanism to add
language-specific components onto the list of files that
come with the base level compiler. For 3.4 we've worked around the
problem, but the workaround is kludgy.
In a related matter, I find it difficult to debug the makefiles that
make use of included makefile fragments. I can see some advantages
of these included files for developers who happen to be working on
those fragments, but overall, the include files make life more difficult.
Same thing goes for the included configure fragments, IMO. And while
I'm ranting, I'd much prefer it the make files were 'for loop free';
that is, that they listed explicit dependencies and built those dependents
in a classic make file fashion, rather than implementing iteration
in the make step. Most of these suggestions argue for a method to
generate make files in a more automated fashion.