From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23530 invoked by alias); 24 Jul 2006 21:42:00 -0000 Received: (qmail 23512 invoked by uid 22791); 24 Jul 2006 21:42:00 -0000 X-Spam-Check-By: sourceware.org Received: from pool-71-248-179-29.bstnma.fios.verizon.net (HELO cgf.cx) (71.248.179.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Jul 2006 21:41:58 +0000 Received: by cgf.cx (Postfix, from userid 201) id 21A2E13C0F1; Mon, 24 Jul 2006 17:41:57 -0400 (EDT) Date: Mon, 24 Jul 2006 21:42:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [RFC] Add expat to the GDB sources Message-ID: <20060724214157.GC25632@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <20060718134048.GA15685@nevyn.them.org> <20060723224032.GA5168@trixie.casa.cgf.cx> <200607232318.k6NNIV28004376@elgar.sibelius.xs4all.nl> <20060724152438.GA17094@trixie.casa.cgf.cx> <20060724195118.GE13612@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00366.txt.bz2 On Mon, Jul 24, 2006 at 11:28:53PM +0300, Eli Zaretskii wrote: >>Date: Mon, 24 Jul 2006 15:51:18 -0400 >>From: Daniel Jacobowitz >> >>On Mon, Jul 24, 2006 at 10:47:54PM +0300, Eli Zaretskii wrote: >>>> Date: Mon, 24 Jul 2006 11:24:38 -0400 >>>> From: Christopher Faylor >>>> >>>> I would really like to see a day when 'src' will no longer include >>>> 'tcl', or 'readline', or 'expat'. >>> >>>But the same could be said about libiberty, libbfd, and libopcodes. >>>Are you saying we should remove them, too, from the GDB distro? If >>>not, what is the difference between those and readline? >> >>In my opinion, the difference is that no independent releases are made >>of those projects. > >They come with GCC and with Binutils. AFAIK, the master for libbfd and libopcodes is in 'src'. I think DJ keeps libiberty in sync so that if you make a change to 'src' it also shows up in 'gcc' and vice versa. >Also, you seem to be saying that, once we remove readline, say, one >would have to use the last released version of readline for building >GDB, while the build out of CVS will still use the CVS version, is >that right? If so, it's a bad idea, IMHO. > >> In an ideal world, maybe there would be independent >> releases, and we could use them. But BFD in particular doesn't have a >> stable API and (as recently discussed on the binutils list) doesn't >> have an interest in one. >> >> Compare to readline, tcl, and expat, each used by hundreds of different >> programs. > >Sorry, I don't see any significant difference. The number of packages >is not really relevant; what is relevant is how easier or harder would >things become for Joe Random Hacker Who Just Wants To Build GDB. I would submit that this is not relevant either. If Joe Random Hacker can't follow instructions for downloading and building an additional package then the chances are not high that he will be able to do any real debugging. It probably isn't really the case, but it sure seems like someone who wants to build a debugger would be slightly more clueful than someone who wants to build, e.g., mplayer. Also, we're not talking about having to track down scores of packages, we're talking about *one* package. If we actually were talking about adding about more packages it would actually make less sense to do something like this. 'src' would be bloated and we'd be in constant package update mode. >Perhaps Chris and Daniel don't see any problem because they have the >latest versions of everything on their machines, at all times. From >my point of view, about the worst annoyance of Free Software is what >happens when I "./configure; make" just to find out that I need two >more packages, which in turn want each one two more packages, which >want yet some more ... > >This is where I usually tell myself "Welcome to Free Software, where >maintainers care about users much less than they care about their own >convenience". (Present company excluded, of course.) I have been in the dependency-chain situation MANY times before and I have *exactly* the opposite feeling. I'm actually pretty heartened to see code reuse in the free software community when it could easily be the other way around. People could just be reimplementing, xml parsing libraries endlessly rather than trying to use existing versions. It sounds like you're advocating that every project which relies on external libraries should include the source code for those libraries. If that is the case, it means that we shouldn't bother with shared libraries at all. Every package would, instead, be bloated by the inclusion of its own version of expat, and openssl, and libtiff, etc. >In other words, when I download a package, I want it ideally to build >out of the box, period. IMO, that is an unrealistic expectation. >No questions asked, and no additional prerequisites that could turn a >simple build job into an agony that lasts the better part of my day, >because each prerequisite package needs a bit of tweaking to build and >install properly. By contrast, when I get readline etc. with GDB, I >can be _certain_ that someone already tried and succeeded to build >_this_ version of the library with _this_ configury and _this_ GDB >release. And, if you are on linux or windows, you can be certain that your version of gdb has a different version of readline than every other package on the system and that gdb is slightly bigger and possibly slightly incompatible as a result. I hate this about insight, also. The problem is even worse there. That is a standard problem with including disparate versions of libraries. But, where does this philosophy end? Are you *really* advocating that every shipping package should include the source code of any libraries that they use? So gdb should also include ncurses? That seems wrong if for no other reason than bug fixes for the library would require changing N packages rather than 1 package. cgf