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 09:17:53 +0100
User-agent: KMail/4.14.10 (Linux/4.3.4-300.fc23.x86_64; KDE/4.14.16; x86_64; ; )

On Sunday 07 February 2016 22:37:11 Mike Frysinger wrote:
> On 07 Feb 2016 13:23, Benno Schulenberg wrote:
> > On Sun, Feb 7, 2016, at 01:03, Mike Frysinger wrote:
> > > On a current Linux system, the size of nano is unchanged.
> > > We start off with importing only a few modules, although
> > > we don't yet delete the fallback logic for them.
> > > ---
> > > 
> > >  .gitignore      |  7 +++++++
> > >  Makefile.am     |  2 +-
> > >  autogen.sh      | 12 ++++++++++++
> > >  configure.ac    |  7 +++++++
> > >  m4/Makefile.am  |  2 +-
> > >  src/Makefile.am |  4 ++--
> > >  6 files changed, 30 insertions(+), 4 deletions(-)
> > 
> > Wow.  So simple?
> > 
> > So, before rolling a tarball, all one does is:
> >   GNULIB_SRCDIR=/path/to/repo/of/gnulib/ ./autogen.sh
> > 
> > and all the rest is automatic: the needed files are copied
> > over to lib/, a Makefile.am is included, and this makes sure
> > the relevant files are also included in DIST.  Wow.  Easy!

Thank you for working on this!

> 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.

Kamil



reply via email to

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