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