(let's move this to popt-devel instead of rpm-devel)
On Oct 25, 2008, at 11:42 AM, Richard W.M. Jones wrote:
On Sat, Oct 25, 2008 at 11:31:49AM -0400, Jeff Johnson wrote:
FYI: patches to <popt-devel@rpm5.org>, please. I'll take
patches however they are sent however. *shrug*
I can't tie builds of popt to gnulib, even for cross-compiles,
there's
way too many
projects that depend on popt.
Gnulib is a source code library, not a "library" library, so in normal
usage Gnulib source files are included in the final tarball:
http://www.gnu.org/software/gnulib/manual/gnulib.html#Library-vs-Reusable-Code
So there's no extra dependency.
Yes, I know what gnulib is.
There most certainly is an extra dependency.
If gnulib is internal, there is additional bloat in the tarball, and
maintenenace of the internal copy.
If gnulib is external, it imposes Yet Another prereqisite for building
popt.
As for whether you store the Gnulib files inside your version control
system, that is a slightly different issue, discussed here:
http://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues
What could be done is disable the usage of glob(3)
if glob is not available through configure tests.
While I agree this is one way to do it, it does mean that Windows
users get one less feature. AIUI globbing is used to implement the
/etc/popt.d/* directory (?), hard-coded in the source unfortunately.
A new port to cross-compiled MingW will never miss the feature.
There's actually another portability issue which Gnulib can help with
in the future - namely, random/srandom missing. I hacked around this
in the patch I just sent, but Gnulib will solve it properly (and also
for other platforms, not just Windows, which lack these calls). I've
got a patch for Gnulib lined up to provide the random family of
functions.
There is nothing in the world (except bero & Ark linux) that
uses or needs the ability to read
/etc/popt.d/*
files.
The /etc/popt.d/* functionality is already conditioned on
#if HAVE_GLOB_H
and should quietly just drop out of -lpopt already.
You already can add the feature by compiling popt with
include (and perhaps library) paths that permit configure
to find glob.h
Meanwhile the other patches to retrofit srand instead of srandom
likely need functionality disabled rather than retrofitted as well,
because
there is little increase in portability if srand is used instead of
srandom. Yes, gnulib might provide srand but not srandom but
that misses the semantic point below.
Truly, when was the last time you needed a CLI option that
returned a random number in a range for any executable purpose
whatsoever?
I cannot justify adding gnulib everywhere for obscure
and undocumented and perhaps pointless -lpopt functionality.
There are way way too many projects that depend on popt to
justify adding gnulib to popt.
OTOH, that's my POV. You are the first ever to suggest adding
gnulib. Find enough support for adding gnulib to popt and I
will certainly do so. ATM, you, and you alone, are the only person
advocating adding gnulib to popt.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
