Daniel Veillard <veillard@xxxxxxxxxx> 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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list