Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd

[David Miller <davem at davemloft dot net>]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Thu, 17 May 2012 22:59:44 +0000 (UTC)

> Does anyone else wish to comment on how comprehensible or intuitive they 
> find the present sysdeps directory structures and ordering, and whether 
> they think incremental cleanups of files and subdirectory levels will make 
> it easier for them to understand the present arrangements as part of 
> contributing usefully towards the design of an improved system?  For 
> myself I find it pretty much at or beyond the limits of comprehensibility 
> at present.

I find it overly complicated at present as well.

One too many times I've had to add debugging to the configure scripts
to figure out why the sysdeps ordering was constructed a certain way.
At other times I've had to walk the sydeps list by hand to figure out
why a certain file ended up being selected.

Not to mention the well understood extreme computational complexity
this scheme has in the context of make due to the amount of prefix
rules that get made to support this.

I find it interesting that when we discuss the abilist files, we want
every port to have all of the abilist files in order to limit the
possibility of accidents.

When, oddly enough, the whole sysdeps structure has that fundamental
problem.

Thinking about this some more, I really like the idea of a target
having to provide a source file for every target object that we would
like to allow to be overridden.

These source files can even be automatically generated early in the
build, from some kind of descriptor file.

Then we'd fundamentally have two prefix rules for building objects,
one that points to sysdeps/PATH/TO/TARGET and one that points to
something like sysdeps/generic.  So we'd have this, instead of how
every many thousands of prefix rules we force make to swallow
currently.

Anyways, just an idea.