Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote:
> > 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?
> 
> The philosophy has always been that one should be able to build a GNU
> toolchain without any external dependencies, to be able to bootstrap
> into a situation wher you can use the toolchain to build other Free
> Software.

(I don't think toolchain in this sense includes GDB.)

Before I work on alternatives for using expat, which I'll be doing
later this afternoon, let me update us on the GNU philosophy on such
issues:

http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries

(quoted below)

While this is not explicit, RMS has made clear that he also disapproves
of GNU packages including other GNU packages without special permission
permission from the FSF, especially if they have local modifications.
Which we do.  We have our own fork of readline.

Examples:
  - Fastjar was removed from GCC by FSF request; this is an equivalent
    issue to expat.  So we should not bundle expat.
  - libgcc-math was removed from GCC by FSF request, because it
    duplicated and slightly modified code from glibc; I believe this
    is equivalent to readline.
  - Soft-fp code from GCC was imported for use in the GCC runtime
    libraries on non-glibc systems, but only after direct permission
    from RMS.

I realize this is somewhat inconvenient for users of GDB, but I think
that if we asked the FSF, they would request we stop bundling readline,
and not bundle expat.

As for optional versus required, I don't think there's a relevant FSF
position.  However, I very much wanted to use the XML target
descriptions in some cases to replace the C-coded ones.  So obviously
I prefer to require expat.

====
So the thing to do in this case is to make your program use the module,
but not consider it a part of your program. There are two reasonable
methods of doing this:

   1. Assume the module is already installed on the system, and use it
when linking your program. This is only reasonable if the module really
has the form of a library.
   2. Include the module in your package, putting the source in a
separate subdirectory whose README file says, This is not part of the
GNU FOO program, but is used with GNU FOO. Then set up your makefiles
to build this module and link it into the executable.

      For this method, it is not necessary to treat the module as a
library and make a .a file from it. You can link with the .o files
directly in the usual manner. 

Both of these methods create an irregularity, and our lawyers have told
us to minimize the amount of such irregularity. So consider using these
methods only for general-purpose modules that were written for other
programs and released separately for general use. For anything that was
written as a contribution to your package, please get papers signed.
====

-- 
Daniel Jacobowitz
CodeSourcery