Re: [patch] Matsushita AM33/2.0 port

[Roland McGrath <roland at redhat dot com>]

> 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.  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.

I don't doubt that there are other gotchas, but we need to see them happen.
For now, I'd say just patch configure.in for your port and see what else
breaks when the rest of the code is in an add-on, so we have a complete
idea of the configure issues before deciding how to change it.

> - having some easy means for not having to pass --enable-add-ons to
>   get an add-on port to be usable.

I already mentioned I had this in mind.  As I said before, let's make ports
work well as explicit add-ons first and then I'll worry about this.

>   of it.  The main stumbling block here are inter-port dependencies,
>   like the common use of #include <sysdeps/.../linux/i386/*.c> in
>   several ports.  I remember having seen such includes referencing
>   other ports as well.  Ports that are referenced this way can't ever
>   be taken out of the core without breaking other ports, or requiring
>   them to be available as add-ons as well.  Fortunately, I can't find
>   relative pathnames, that were my main concern when I started typing
>   this paragraph, but we should be aware they should be avoided to
>   make sure ports can turn from drop-in add-ons to part of the core,
>   and vice-versa.

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.

> No problem here.  I just wish we could have add-on parts in the glibc
> repository, just like linuxthreads and nptl, such that it's a single
> check out.  I don't want you guys to spend (waste? :-) time
> maintaining this port, I'd just like it to be easier to figure out
> what add-on ports there are, and be able to get them all at least for
> inspiration when creating a new port.  I'd also like for add-on ports
> to be packaged and tagged along with official glibc releases, but I
> suppose you'd rather not do that.

As I said, we will work with you to make things easy for users and
maintainers.  This is the kind of stuff that entails.  
But one thing at a time.

> Thanks, I'll get this effort started later today.

It's very much appreciated.


Thanks,
Roland