An article about the Cygnus tree
Wed Sep 6 12:46:00 GMT 2000
Joe Buck <email@example.com> wrote:
> I am starting to see the problem. You are confusing several things
> together and mashing them into one concept that you are calling "the
> Cygnus tree".
No, I'm not confusing anything.
> what you're failing to see is that this system was designed so that
> a GNU source directory can be made a subdirectory and then built *without
> changing it*.
No, I'm not failing to see this, I know this very well.
> Since you don't appreciate that, you falsely believe that
> a huge change had to be made to gcc to get it to build within this
No, I know that there was no big change at that early stage. The big changes
came when the original non-Cygnus-tree GNU packages went away and the ones in
the Cygnus tree became the only ones remaining, at the same time undergoing a
transformation to become dependent on the top level and on other modules. This
was certainly much more significant for Binutils and GDB, but I'm arguing that
GCC is really no different.
I'm sorry that you've failed to see the whole point of my article, which is to
persuade the powers that be to merge the src and gcc repos. What's keeping GCC
in its own repo are the people on the GNU side of things who see it as
independent from the Cygnus tree. But what I'm arguing in my article is that
this perception of GCC's independence from the Cygnus tree by some GCC
maintainers is bogus. To become really independent, they would have to really
break all ties with the Cygnus tree, removing the top-level configure script
and Makefile that support the rest of the tree and taking away the single tree
build. I very seriously doubt that they'll be able to do that, unless they
commit the change anonymously so that the angry mob of embedded developers
using the single tree build doesn't get them, and if they are not going to do
that, they are still tied to the Cygnus tree whether they are in the main repo
with the master copies of the top-level files or using stale mirrors of those
files in their own repo, and everyone would benefit and no one would lose
anything from switching to the former.
> Concept #2 is the CVS archive that Cygnus (now Red Hat) makes releases
> from for their own customers. This tree is *not* the same as the "net"
> version of gcc (or egcs before it). In many cases, work that Cygnus did
> went to customers first and only later was merged into the egcs or GCC
I know that there are two Cygnus trees, one internal and one public, with the
former being very old and the latter not being complete yet because of
someone's reluctance to merge /cvs/src and /cvs/gcc on the Sourceware box. This
is explained in my article too, clearly enough I think. And I also know that
the differences between the two are generally kept to a minimum. Also don't
forget that before the public CVS repos were created, there were still public
daily or weekly snapshots. I can bet that those were made directly from the
trunk of Cygnus' internal repo, proving that it can't be too far away from what
the public is allowed to see. As for customer stuff, that's on branches, not on
the trunk, or so I've heard.
And still note the big problem with your wording. When you talk about the
public tree, you are again talking about a separate tree for GCC or EGCS rather
the a public version of the full Cygnus tree. *There is no separate GCC or EGCS
tree, other than as a nuisance to the developers and users in the two-repo
arrangement*. There is a public Cygnus tree now, in /cvs/src on the Sourceware
box, which closely mirrors the structure of the old internal tree and contains
all of its components that Cygnus was willing to make public, whether they are
used in GNU projects (like bfd, opcodes, etc) or are completely non-GNU (like
newlib, libgloss, winsup, etc). GCC is the only remaining exception, and I'm
doing everything I can to persuade the powers that be to realise that it's no
different from everyone else (including Binutils and GDB, which are just as GNU
but happily live in the unified public Cygnus tree) and to merge the src and
Haven't you noticed lately that every change to the top level has to be
carefully applied to both /cvs/src and /cvs/gcc repos? If you have, how can you
still think of a separate GCC tree?
Michael Sokolov Harhan Engineering Laboratory
Public Service Agent International Free Computing Task Force
International Engineering and Science Task Force
615 N GOOD LATIMER EXPY STE #4
DALLAS TX 75204-5852 USA
Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)
More information about the Gcc