[Libvir] using gnulib: starting with the physmem and getaddrinfo modules

[Jim Meyering]

Daniel Veillard <veillard at redhat.com> wrote:
...
>> This change brings in a lot of code, but many of the lib/.[ch] files
>> are used only on systems that lack some required functionality.  For
>> example, the getaddrinfo.c file isn't even compiled when it's not
>> needed.
>
>   My main concerns were over:
>     - an 'invasion' of a lot of different code in libvirt own code base
>       and the associated maintainance duties
>     - Licencing problems, we are LGPLv2 and should be very careful to
>       not import in the library code which would break it even inadvertently
>
>> In the patch below, I've included a new script called bootstrap.
>> It is a wrapper around gnulib-tool that pulls into libvirt the
>
>   Like Dan I don't like this too much, we should have the files in CVS
> and not require dynamic fetching. Moreover this just fails for me here
> after applying the patch, the final patch should include everything
> needed to
>   ./autogen.sh ; make ; make check
> both from a CVS checkout and from a tarball without assuming network
> connection.
>
> paphio:~/libvirt -> sh bootstrap
> bootstrap: getting gnulib files...
> bootstrap: line 50: git: command not found
> bootstrap: line 51: cleanup_gnulib: command not found
> bootstrap: line 59: gnulib/gnulib-tool: No such file or directory
> paphio:~/libvirt ->

Yes, the script requires that you have "git" installed.
However, with you three against my one, we don't have to worry
about this anymore :-)  I'll continue to include the bootstrap
script as the reference for how to import or update.

>> files selected by the (currently two) modules in use.  Those new
>> files go in three places:
>>
>>   m4/*.m4
>>   lib/*.[ch] and a few template .h.in files
>
>   Hum, if lib/ ends up containing only files coming from gnulib it's
> probably better to name it after it, that way it will be clear where
> this originates from
>
>>   gl-tests/ for unit test C programs and Bourne shell scripts
>
>   should be in tests/gnulib/ or something similar, I concur with Dan
> on this,

I'm easy on the names.
I've adjusted to use these:

  gnulib/m4
  gnulib/lib
  tests/gnulib

>> However, note that gettextize and libtoolize (run by autogen.sh)
>> also deposit many *.m4 files in m4.  I compared and found that 8
>> of the files that are already pulled in by the *ize programs are
>> also pulled in (potentially newer versions) from gnulib.  But currently,
>> using gettext-0.16.1 or gettext-0.17, there is no difference in any
>> of the overlapping files.
>
>   We need to find a way, Dan suggested a mechanism,
>
>> Re Licenses: the two modules (and all of their dependent modules)
>> are LGPL-compatible.  This is enforced by running gnulib-tool
>> with the --lgpl option.  If you were to request a module with
>> an incompatible license (say GPL or LGPLv3), it would fail.
>
>   Can we make qa static check at commit time ? We really need everything
> in CVS and checking individually all added files before commit sounds the
> right way to make sure there is no problem.
>
>> ----------------------
>> Here's the patch that shows what existing parts of libvirt have to
>> be modified to use these two new modules.  To try it out, just apply
>> the patch and then run this:
>>
>>     ./autogen.sh && ./bootstrap && make && make check
>>
>> Running bootstrap creates the new lib/ and gl-tests/ directories.
>
>   well it fails for me, but the patch applies fine.

It should work if you install git.

>> Personally, I prefer not to add generated files to version control
>> systems, because it can lead to problems with version skew if all
>> developers don't use the same releases of the tools that do the
>> generating.  Perhaps more importantly, when there are massive diffs in
>> the generated files, that can obscure real changes in non-generated parts
>> of the code.  That already happens to me whenever the .po files change.
>>
>> But if people prefer to add all of these imported files to CVS, just
>> say the word and I'll prepare the patch.  If so, do you guys want the
>> gettextize- and libtoolize-added files to be version-controlled, now, too?
>
> Basically everything needed for autogen/build/check/install whould be in CVS.

Yep.  I get the message :-)

...
>   One thing I really wonder though is suppot of that code when using
> Microsoft compilers on the various Windows platforms. Are those part of
> the target for gnulib. That's in my experience with libxml2 some of the
> place where the most tricky problems could be reported, so if this
> could help there theis would be a big argument for gnulib inclusion,

The compilers are less of a problem than the environment.
We encourage people to use cygwin or mingw, since they're
closer to being POSIX-compliant than the M$ environment.

More and more people are discovering that gnulib works for Windows too,
so there are more contributors.  While the primary goal is to make things
portable for Unix-based systems, we have never turned down high-quality
patches.