nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] [PATCH 1/8] add support for gnulib


From: Kamil Dudka
Subject: Re: [Nano-devel] [PATCH 1/8] add support for gnulib
Date: Mon, 08 Feb 2016 16:30:15 +0100
User-agent: KMail/4.14.10 (Linux/4.3.4-300.fc23.x86_64; KDE/4.14.16; x86_64; ; )

On Monday 08 February 2016 10:17:51 Mike Frysinger wrote:
> On 08 Feb 2016 09:17, Kamil Dudka wrote:
> > On Sunday 07 February 2016 22:37:11 Mike Frysinger wrote:
> > > GNULIB_SRCDIR is a semi-common dir, so i tend to export it in my
> > > profile.  some projects will autobootstrap a copy locally, but i
> > > don't know if you want to get that crazy.
> > 
> > What I am missing with this approach is a machine readable hash of gnulib
> > snapshot that nano source code should be compiled against.  Without such
> > info maintained in the git repository of nano, it is nearly impossible to
> > git-bisect nano source code after a longer period of time.  Old version
> > of nano will not compile against newer gnulib code and vice versa.
> 
> this is probably why other projects treat gnulib as a git submodule.
> since nano is still based in svn, not sure it's possible to do that.
> which means the external git sha1 would need be updated by hand in
> the autogen.sh file.
> -mike

That would work for me.  For example GNU findutils keeps the hash in a file 
named import-gnulib.config.  The actual file does not matter as long as it
is tracked by SCM and gnulib is always (or at least by default) checked out 
based on that info.

If you let autogen.sh use a random gnulib snapshot from developer's machine, 
older revisions of nano would be difficult to build automatically few years 
from now.

Kamil



reply via email to

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