[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Libvir] using gnulib: starting with the physmem and getaddrinfo modules
- From: Jim Meyering <jim meyering net>
- To: veillard redhat com
- Cc: Libvirt <libvir-list redhat com>
- Subject: Re: [Libvir] using gnulib: starting with the physmem and getaddrinfo modules
- Date: Wed, 05 Dec 2007 14:10:17 +0100
Daniel Veillard <veillard 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
> 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
> 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:
>> 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:
>> 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
[Date Prev][Date Next] [Thread Prev][Thread Next]