AIX status

Ulrich Drepper drepper@redhat.com
Sun Oct 15 18:39:00 GMT 2000


Mark Mitchell <mark@codesourcery.com> writes:

> It would be nice if there were actually a project-wide definition of
> first-tier platforms; then each individual maintainer/committee would
> not have to decide this problem.

Project-wide is not possible.  gcc can have AIX in first tier, but it
does not mean it's in the same category for libstdc++.  There is a much
greater dependence on the environment in libstdc++ and that is the
problem.  AIX is making this horribly hard.

How it should work is that by default *all* platforms are second tier.
If somebody steps up and takes timely responsibilities for an arch/OS
combination, fine, it can be promoted.  This should happen once a
certain track record is established.  You see that this works for
Linux (almost all archs) and also Solaris.

It does not work at all for AIX.  It might be in wide (wider than?) 
use but not with developers.  The consequence is what we see right
here.

David's attitude is not helping here at all.  He simply demands that
AIX is handled by those who are working on other architectures (one of
the arguments is, btw, that you, Mark, made a working AIX port a
release criteria for gcc).  This is plainly wrong.  People working on
the code have no obligation at all for non-existing ports.  If
somebody has an interest in seeing a port done s/he has to do it
her/himself or pay somebody to do it.

This is not what happens here.  Far too many people have to work on
the AIX stuff even though it's not in their interest.  At this point
it is also important to notice systems which disrupt the source code
base too much.  Sharing as much code as possible is good, but if a
system is simply too different separate files must be used.  The
libstdc++ directory structure was designed to allow exactly this (it's
largely based on what we do in glibc).  I.e., simply have the new port
create a new file instead of polluting existing code with tons of
#ifdefs and similar bestialities.


Then it comes to the time when a port is finished.  Now the rules
change a bit: changes should not deliberately break some supported
platforms and best efforts should be made to repair the damage.  But
again, it's the duty of those having the interest in the port to
ensure that nothing is broken.  Most people don't have access to
systems except those they are using themselves.  If then one of the
ports makes sharing code hard by deliberately diverging from common
practice contributors cannot be blamed for breaking other ports.  This
is just another reason to create separate sources for some parts of
the library.


David deliberately misrepresented both the reasons and the effects of
this:

- it is not the case that a system (AIX) is judge bad; judgment is
  based on and about the design of the interface which in this case is
  so very much different that a change can have very bad effects even
  though it works fine on all the other systems.  And yes, difference
  from the standard is bad.

- using different files does not mean that those systems are declared
  second tier.  It just protects the sources from being unnecessarily
  uglified, avoids changes which cannot be tested, and also underlines
  the responsibility of the port maintainer to do a continuous job.


All this is how free software is developed for years.  David knows
this, of cause, since he is everything but stupid.

The aggressive, demanding, sometimes hostile attitude he shows comes
most probably from the fact that he set himself the goal (or had his
bosses set the goal for him) to get all these things working on AIX
and his other projects.  It is wrong to behave like this.  If you have
to do the work because you are told so you cannot force volunteers to
help you.  It's also not you, David, who makes the design decisions.
It's Benjamin and whoever he wants to consult.

I don't say that David hasn't realized this at all.  After the initial
tries failed to attract any volunteers he came up with patches.  But
deciding about the acceptance is up to the maintainers as is
requesting changes to be made.  Also, as long as the underlying tools
(I mostly think about libtool) are not fully supporting the
architecture all other points are mood.  And to make these tools work
correctly the same kind of problems must be overcome.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------


More information about the Libstdc++ mailing list