Re: [patch] Matsushita AM33/2.0 port

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun 18, 2004, Roland McGrath <roland@redhat.com> wrote:

> Please see the prior thread here (came up with the Xtensa port) on what
> this is about.  I think I addressed all your concerns in great detail there
> already.

I thought you'd meant the technical concerns.  I'm well aware of the
rationale for the glibc maintainers to prefer to not spend time on
ports that are not...  Heck, I'm not sure how to express this in a way
that doesn't make it sound like I disagree with you, but I perfectly
understand the situation, and I'm all for not giving you guys more
trouble to maintain ports that few people care about.


My main concerns were technical ones, and the ones I'm most worried
about at this moment are:

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

- having some easy means for not having to pass --enable-add-ons to
  get an add-on port to be usable.  Requiring such a flag may sound
  acceptable for the glibc CVS tree, but when we ship a glibc port to
  a customer, it's no longer an add-on, it's the most important bit
  there.  Having to configure that with --enable-add-ons is
  misleading and confusing.

What I'm thinking is to have some configure variable that is set to
empty by default, but that, when we package an add-on glibc port for a
customer, we can adjust that variable such that the add-on is
considered by default.

What would be even nicer would be some early probe mechanism, in which
glibc would look for add-on ports in some standard location (I'm
thinking of something along the lines of ports/*/auto-enable.sh) that
can look at the configured host name and decide whether to add the
port to the add-ons list, as if it had been specified in the command
line, and set any early config settings the port might need if so.


- making it easy for ports to be added to the glibc core, or taken out
  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.

> It doesn't need to be a pain at all.  You can call it silly to have it
> alongside glibc in the sources repository, but that distinction is
> important to the core glibc maintainers and you will just have to humor us.

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.

>> Depends on the amount of work involved.

> Plop all your new sysdeps tree files into an add-on directory, configure
> --enable-add-ons=...,my-port-dir, and then start complaining about what
> breaks.  I will help fix it.  Once having a port live in an explicitly
> configured add-on works, I will tinker with some approaches to making a
> canonical collection of add-on ports easy to use.

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

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