RPM Community Forums

Mailing List Message of <popt-devel>

Re: [PATCH] Compile popt under Windows using gnulib

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 25 Oct 2008 - 18:12:18 CEST
Message-id: <4F524356-6F7E-48A1-9B95-2F1F27C337B7@mac.com>
(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
Received on Sat Oct 25 18:12:24 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.