Re: srcdir builds & other stuff

[Nathanael Nerode <neroden at doctormoo dot dyndns dot org>]

Benjamin Kosnik quoth:
>This is a bummer. 

>Would it be possible to come up with a long-term design plan WRT the
>configure/make parts of gcc, including the target libraries? 

>In particular, staging the build libraries and includes in a way that
>mimics the directory layouts of the final install seems to be an idea
>that is repeatedly mentioned as advisable, yet is never implemented. I
>would like to see this, as I think it would greatly simplify testing
>hooks and would also bring sanity to cross compilation parts of make
>and configure.

I'm going to do this (following Per Bothner's plan) soon after I finish
doing autoconfiscation; I considered doing it first, but decided people
probably wanted autoconfiscation ASAP.  Although I'm not sure
autoconfiscation will be in by 3.2, I'm pretty sure it will be in by
stage 1 of 3.3, which means I'll probably have at least part of that
rearrangment in by 3.3.  (It's an incremental scheme, so partly-done is
fully functional.)

When the autoconfiscation arrives, it will become incredibly evident
what will be simplified by the build process change; I deliberately
isolated all the special-case code to find things in the build
directories.

(Oddly enough, half of the autoconfiscation work consisted of pure cruft
removal, simplification, and reorganization... I guess nobody had
cleaned up those files in a long time.)

Speaking of the autoconfiscation, I promise, it's coming Real Soon Now.
I'm going to work up the fifth version (*grin*) this week and start
subjecting it to really, really heavy testing (ubertree crossbacks!)
The fourth version basically worked but was low on readability, hence
all the reorg changes I've been doing.

I will probably be delayed by uncovering bugs (*outside* my work) in
obscure build combinations, and having to verify that they were
pre-existing.  (so for every build I try there's going to be an 'old'
and a 'new' version for me to compare.  Will take a while.)

Diego Novillo quoth:
>On Mon, 2002-06-24 at 11:34, Benjamin Kosnik wrote:
>> Would it be possible to come up with a long-term design plan WRT the
>> configure/make parts of gcc, including the target libraries? 
>> 
>Alternatively, couldn't all this experimentation be done on a branch?

1. I don't have write access to the CVS repository at all, so working on
a branch is not really a happy thing for me.  
2. The top level has to be kept synchronized with src.  Having a branch
causes pain because the *branch* would have to separately be kept in
sync with src, probably a branch in src.
3. The scheme I have been using to deal with things has been
quite cautious; it's slow, but it hasn't introduced any regressions yet.
Per Bothner's scheme for rearranging the build process similarly is a
slow, transitional scheme that is designed to make it very hard to break
things during the process.  Accordingly, the only bugs which are going 
to show up will be obscure and hard to run into, and so mainline is most
appropriate due to being most heavily tested.
4. The changes change a limited number of things, but the files they
change most often are fast-moving targets.  Merging branch into main
will suck for this kind of change.  Also the build process
changes will change a *lot* of files in trivial (search-and-replace)
ways, which is another potential irritation for merges.
5.  The incremental changes we're making are, mostly, valuable in and of
themselves, so it's nice to put them straight into mainline.

*cough*

Changes like the 'phony Makefile, create new directory if
srcdir=builddir' stuff, which I am avoiding, probably do belong on a
branch.

--Nathanael
--waiting for current patches to hit mainline--