PATCH [1/n]: Initial x32 support

[Roland McGrath]

> The idea is that all of them would be run (whatever directory they are 
> in), just as they are in add-ons (with the same convention that it's a bug 
> for such a fragment to do anything for an unrelated target), but logically 
> sysdeps directories seem a better place for architecture-specific logic 
> that sets base_machine than toplevel configure.in does.

Then perhaps I misunderstood your intent.  When you say "sysdeps foo", I
assume you mean $(wildcard $(sysdirs:=/foo)).  preconfigure as it stands is
a singular special case, because it's just ${add_on}/sysdeps/*/preconfigure
so it can only be in the top-level CPU directories (or it could be in the
top-level OS directories or other top-level directories like wordsize-NN,
though it was originally intended only for CPU directories).

If what you propose is just sourcing ${srcdir}sysdeps/*/preconfigure before
${add_on}/sysdeps/*/preconfigure, then I suppose that is alright.  I'm not
especially convinced it's not more baroque to do that than just to have the
logic directly in the top-level configure.in.  But it does mean that an
(appropriately disciplined) add-on port becomes an integrated port just by
adding its files directly the main tree, which is an attractive notion.


Thanks,
Roland