[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
signature.asc
Description: Digital signature
- Re: [Nano-devel] [PATCH 1/8] add support for gnulib, (continued)
Re: [Nano-devel] [PATCH 1/8] add support for gnulib, Benno Schulenberg, 2016/02/07