This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Add expat to the GDB sources
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