[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
- [Nano-devel] [PATCH 7/8] drop glib fallback for snprintf/vsnprintf, (continued)
Re: [Nano-devel] [PATCH 1/8] add support for gnulib, Benno Schulenberg, 2016/02/07