> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
