Gnulib for non C programs.

Gnulib for non C programs.

[Mathieu Lirzin]

Hi,

For C projects, it is really convenient to use Gnulib as a Git submodule
and let ‘./bootstrap’ do the job.  However in the case of GNU packages
which don't use C, It is a bit overkill to clone a full repository only
for some maintenance scripts and a robust bootstrap script which fetches
.po files.  The alternate option is to check the files in the
repository, sync them manually and maintain a specific bootstrap script.
IMO this is not ideal.

I would like to know if it would be acceptable to modify Gnulib
bootstrap in order to support fetching maintenance scripts using
rsync|wget (like what is done for .po files).  An idea would be to
trigger this behavior when having the '--no-git' option without
'--gnulib-srcdir' set.

What do people think?

--
Mathieu Lirzin

Re: Gnulib for non C programs.

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

On 14 Jan 2016 00:59, Mathieu Lirzin wrote:
> For C projects, it is really convenient to use Gnulib as a Git submodule
> and let ‘./bootstrap’ do the job.  However in the case of GNU packages
> which don't use C, It is a bit overkill to clone a full repository only
> for some maintenance scripts and a robust bootstrap script which fetches
> .po files.  The alternate option is to check the files in the
> repository, sync them manually and maintain a specific bootstrap script.
> IMO this is not ideal.
> 
> I would like to know if it would be acceptable to modify Gnulib
> bootstrap in order to support fetching maintenance scripts using
> rsync|wget (like what is done for .po files).  An idea would be to
> trigger this behavior when having the '--no-git' option without
> '--gnulib-srcdir' set.
> 
> What do people think?

is it really that big of a problem to fetch 10MiB of data ?
$ git clone --depth=1 git://git.sv.gnu.org/gnulib.git
Cloning into 'gnulib'...
remote: Counting objects: 9369, done.
remote: Compressing objects: 100% (8310/8310), done.
remote: Total 9369 (delta 5065), reused 2198 (delta 1038)
Receiving objects: 100% (9369/9369), 7.56 MiB | 1.94 MiB/s, done.
Resolving deltas: 100% (5065/5065), done.
Checking connectivity... done.
$ cd gnulib
$ du -s -h .git
8.8M    .git
$ du -s -h .
69M
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Gnulib for non C programs.

[Karl Berry]

    sync them manually 

FWIW, this is precisely what gnulib/config/srclist* is about: keeping
individual files in sync between different places, unrelated to any
"module" concept.  It is not gnulib-specific (or git-specific or
anything-specific).  -k

Re: Gnulib for non C programs.

[Mathieu Lirzin]

Mike Frysinger <vapier@gentoo.org> writes:

> On 14 Jan 2016 00:59, Mathieu Lirzin wrote:
>> However in the case of GNU packages which don't use C, It is a bit
>> overkill to clone a full repository only for some maintenance scripts
>> and a robust bootstrap script which fetches .po files.
>> [....]
>> What do people think?
>
> is it really that big of a problem to fetch 10MiB of data ?
> $ git clone --depth=1 git://git.sv.gnu.org/gnulib.git
> Cloning into 'gnulib'...
> remote: Counting objects: 9369, done.
> remote: Compressing objects: 100% (8310/8310), done.
> remote: Total 9369 (delta 5065), reused 2198 (delta 1038)
> Receiving objects: 100% (9369/9369), 7.56 MiB | 1.94 MiB/s, done.
> Resolving deltas: 100% (5065/5065), done.
> Checking connectivity... done.
> $ cd gnulib
> $ du -s -h .git
> 8.8M    .git
> $ du -s -h .
> 69M

I didn't know about the --depth option.  Thanks for making me learn
something.  :)

I have just realized that using a Git sub-module for Gnulib is much more
heavy weight than letting bootstrap automatically clone the latest
version of Gnulib with '--depth=2'.  My experience with Gnulib was more
like that:

--8<---------------cut here---------------start------------->8---
./bootstrap: getting gnulib files...
Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 'gnulib'
Cloning into 'gnulib'...
remote: Counting objects: 166232, done.        
remote: Compressing objects: 100% (24259/24259), done.        
remote: Total 166232 (delta 141984), reused 166129 (delta 141915)        
Receiving objects: 100% (166232/166232), 31.47 MiB | 767.00 KiB/s, done.
Resolving deltas: 100% (141984/141984), done.
Checking connectivity... done.
Submodule path '.gnulib': checked out '9a7c87c5a5ccb1ab2d5b67bc9b3b8d7ae0fa4377'
--8<---------------cut here---------------end--------------->8---

So I agree with you that the current behavior (without sub-modules) is
adapted for the use case I have described.

--
Mathieu Lirzin

Re: Gnulib for non C programs.

[Mathieu Lirzin]

Karl Berry <karl@freefriends.org> writes:

>     sync them manually 
>
> FWIW, this is precisely what gnulib/config/srclist* is about: keeping
> individual files in sync between different places, unrelated to any
> "module" concept.  It is not gnulib-specific (or git-specific or
> anything-specific).  -k

I didn't know about this.  I still prefer the idea of keeping Gnulib
files out of VCS, but indeed this provides some nice automation.

Thanks for sharing.

--
Mathieu Lirzin