bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gplv3 files and updates


From: Paul Eggert
Subject: Re: gplv3 files and updates
Date: Fri, 13 Jul 2007 11:41:39 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

address@hidden (Karl Berry) writes:

> But nowadays my understanding is that coreutils, and
> every other project, uses gnulib-tool.

The problem occurs even when gnulib-tool is being used.  A common way
for developers to use gnulib-tool, which I use in many projects (not
just coreutils), is something like this:

  ./bootstrap --gnulib-srcdir=../gnulib

This invocation of "bootstrap" uses gnulib-tool but bootstraps off of
symbolic links to my local copy of gnulib, which is much faster than
pulling a gnulib copy from the Savannah CVS.  More important, it lets
me bootstrap from a modified version of gnulib before committing the
gnulib changes to CVS.

If this sort of bootstrap were changed to make copies rather than
symbolic links, it would be much more of a pain to develop when
changes to both gnulib and an application are being debugged.  It
would be far too easy to mistakenly edit the coreutils copy of a
gnulib file rather than the original; and later, when everything is
checked in, some of the gnulib fixes would be lost.  I speak from sad
experience here, because that is the way I used to develop, before I
started using symbolic links.  It was a real pain.

Going back to using copies (instead of symbolic links) when
bootstrapping would not merely be a minor annoyance for me; it would
be a real hassle and would make the resulting programs less reliable.

I hope this helps to explain the technical considerations better.

> I know of no other extant example of licenses being manifestly converted

Me neither.  But gnulib is special in many ways.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]