This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH [1/n]: Initial x32 support
> 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