This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [patch] Matsushita AM33/2.0 port
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: 18 Jun 2004 23:29:31 -0300
- Subject: Re: [patch] Matsushita AM33/2.0 port
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <200406182249.i5IMnI2x013259@magilla.sf.frob.com>
On Jun 18, 2004, Roland McGrath <roland@redhat.com> wrote:
>> My main concerns were technical ones
> These are exactly the things I'd like to get fixed.
>> - getting ports to be able to set things up early enough in the
>> top-level configuration process. add-ons' configure bits don't get
>> run early enough.
> Please be specific. Which port-specific work do you need configure to do?
> All I know of is the base_machine/base_os setup.
This is exactly what I had in mind.
> I think we can replace that hard-coded stuff with a table of
> patterns in a file, and then have configure use the union of files
> from all add-ons.
How would this work for mips64*-linux, for example?
A configure-let script would address both this issue and that of
automatic add-ons. We just need a convention on where these files
should be placed and how they should be named.
>> of it. The main stumbling block here are inter-port dependencies,
>> like the common use of #include <sysdeps/.../linux/i386/*.c> in
>> several ports.
> That is a reasonable concern. When any existing port is moved out of the
> core, we will be sure to test building all remaining ports still in the
> core with no add-on ports present.
Excellent. It's a bit sad that add-on ports won't be able to use
common bits from each other, but I guess this is something we'll just
have to live with.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}