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: Mike Frysinger
Subject: Re: [Nano-devel] [PATCH 1/8] add support for gnulib
Date: Tue, 9 Feb 2016 03:06:25 -0500

On 08 Feb 2016 16:30, Kamil Dudka wrote:
> 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.
> 
> 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.

i'm fine with encoding the hash.  i'll let Benno shake things out a bit
more before reposting though.
-mike

Attachment: signature.asc
Description: Digital signature


reply via email to

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