On 10/25/2012 08:15 AM, Thomas Martitz wrote: >> This has been asked before on this list, and the answer has always been >> that it is more work than worth the effort, and that gnulib-tool is the >> preferred way to use gnulib source code. >> > > I cannot really understand your reasoning as it makes it hard to > discover that less restrictive license terms are also possible. I > wouldn't have found that LGPLv2+ is no problem if I didn't go through > the "hassle" of writing mails and subscribing to this mailing list.
You don't have to subscribe to bug-gnulib to post here. List policy here (as on many other GNU lists) is to allow anyone to post, and to use reply-to-all so that non-subscribers still stay part of the thread. Picking and choosing just a .c file is too likely to go wrong - most of gnulib depends on also picking up .m4 files, replacement .h files to work around broken system headers, and module dependencies. To really use a module, you have to use the full information under the modules/ directory - and gnulib-tool really is the easiest way to use this full information, including licensing terms. > Perhaps it could be made more prominent on the gnulib website, at least. What page would you suggest enhancing to more prominently call out the fact that we recommend gnulib-tool as the way for using gnulib files? > > Additionally it means extra work when merging upstream fixes harder, > which is unfortunate. On the contrary, I find gnulib-tool quite easy to use; much easier than the counterpart of trying to hand-pick multiple files to copy into place. > > But if you have determined that this approach works better for you I'm > not going to question it any further. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
