From mboxrd@z Thu Jan 1 00:00:00 1970 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: An article about the Cygnus tree Date: Mon, 04 Sep 2000 21:19:00 -0000 Message-id: <0009050418.AA27627@ivan.Harhan.ORG> X-SW-Source: 2000-09/msg00022.html David Edelsohn wrote: > I find your "Introduction to the Cygnus Tree" to be riddled with > incorrect statements. I do not understand why you apparently made no > attempt to investigate the facts before publicly releasing a thoroughly > inaccurate document. I *did* investigate most of the facts. I have been watching these facts unfold for a while now, I've been saving all the important bits of information about this stuff I've come across in the past (even though I didn't need them then), and I've done some CVS repo archaelogy. I did miss a few fine points, but you could have certainly been a little more polite in pointing them out. > Cygnus, as a company, never has been the official FSF-appointed > maintainer of *ANY* GNU Project package. I didn't say that they were FSF-appointed maintainers. That is politics that I prefer to stay out of. I was and am focusing on the *technical* aspect of the transition. First there were GNU packages with all their "meat" at the top directory level. The Cygnus tree had versions of them grafted under the top- level configure script and Makefile. What was so remarkable about the transition from FSF's gcc2 to EGCS/GCC, and the much earlier transition in Binutils and GDB that I, perhaps incorrectly, referred to as Cygnus takeover, is that the FSF packages with the "meat" at the top directory level *went away* and the version of the program in the Cygnus tree became the master one, with all subsequent EGCS or FSF tarballs being made from the Cygnus tree and carrying top-level configure scripts and Makefiles telling curious code readers about the rest of the tree. Also when I say "Cygnus tree", I'm not picking on them as a company. (And yes, I know that they are Red Hat now.) I call it the Cygnus tree for exactly the same reason why the configure script at its top is universally known as Cygnus configure and called this way by everyone, and why the Automake option enabling special rules for this tree is named cygnus. In fact, I took the name Cygnus tree from configure.texi, before I read that I didn't know how to call it. And while I think this is stated clearly enough in the article itself, let me repeat: the previous point (that I wasn't even sure what to call it) is the essense of the problem that needs a solution: there is a sore lack of public tutorial information on this animal. There is a home for the GNU project and there are home pages for all GNU projects, and as a result, everyone knows what they are and where to get them. But it's very hard to explain to a newcomer what the Cygnus tree is. See below. > Daily and weekly snapshots of > the various packages (gcc, gas, gdb, and binutils) were available to all > active developers prior to the public CVS repositories; I know this, and I never said otherwise. > The hosting of the gcc.gnu.org site by Cygnus/Red Hat is not a > "dirty little secret". When writing that, I assumed that everyone reading those words would understand them as tongue-in-cheek. Your reaction shows that I was wrong. Sorry 'bout that. That and all the language about "conspiracies" was intended to convey that the lack of a home for the tree overall, as opposed to its individual modules, makes it look like a conspiracy. *Of course* I know that everyone working on this code is extremely devoted to free software and that there are no conspiracies. I was pointing it out that there is a problem with not having a home for the unified Cygnus tree and that it makes it look like a conspiracy. > Whatever ax you have to grind [...] I don't have any axes to grind, and I'm very sorry that you have so completely misinterpreted my article. I really don't think I could have made any clearer: in the article itself I have clearly stated more than once why I wrote it and what I'm trying to achieve. I think I have explained it as well as it could be in the article, so repeating it here would be just wasting bandwidth, but let me repeat it very briefly. I have projects that use the Cygnus tree instead of discrete releases from ftp.gnu.org. These projects have found it unacceptable to build bfd and opcodes twice and libiberty three times. I, being a developer and knowing the "secrets" (tongue-in-cheek) which most developers know but which are not written down in ASCII anywhere, have no problem with this and have found the compilation time reduction and ease of development tracking very pleasant. But right now I'm in the process of preparing a release, and this is where I hit a problem. It's trivial to tell your users "this system uses GCC, Binutils, and GDB, go get them". But it's infinitely harder to tell them that a system uses the Cygnus tree, given that there is no home for it where people can learn what it is, that there is no single repository to get it from, and that a lot people don't even know that such a thing exists (been there myself). First all I wanted to do was to explain the procedure for piecing together the tree from the two repos. But before I even got there, I at least had to say *what* does one need to build. I needed to refer to the Cygnus tree. It's trivial to say "this system uses GCC" and point to its WWW page. But for the Cygnus tree there isn't any. In Free Software when you need something that does not exist, you create it. This is exactly what I did in writing my article. And of course after having explained the horrible procedure for piecing together the tree when the correct solution (repo unification) is obvious, it was only proper to make a call for action to actually implement this correct solution. > [...] before you start patting yourself on the back for getting > things rolling. I was never planning on doing that actually. Anyway, I have checked in version 1.4 of cygnus-tree-intro with the language changed so that hopefully fewer people will get offended by it and more people will gain useful insight from it, which was its original intent. It is in ivan.Harhan.ORG:/pub/embedded/cygnus-tree-intro. -- 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)