[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] pod2man --utf8 -> wget build failure

From: Tim Rühsen
Subject: Re: [Bug-wget] pod2man --utf8 -> wget build failure
Date: Tue, 24 May 2016 20:37:53 +0200
User-agent: KMail/4.14.10 (Linux/4.5.0-2-amd64; KDE/4.14.20; x86_64; ; )

Am Dienstag, 24. Mai 2016, 09:24:44 schrieb Ryan Schmidt:
> On May 24, 2016, at 5:55 AM, Tim Ruehsen wrote:
> > Hi Karl,
> > 
> > thanks for pointing out those issue(s).
> > 
> >> Perl... Exactly which version does not matter.
> > 
> > It matters. AFAICS, Perl 5.8 introduced UTF-8 in 2002.
> > So perhaps your system is even older !?
> > (Just out of curiosity, what is it ?)
> MacPorts users observed this problem with Mac OS X 10.6 "Snow Leopard",
> which was released in 2009.
> https://trac.macports.org/ticket/50164
> We addressed it by using a newer pod2man installed by MacPorts instead of
> the older one included with OS X.
> > That lets me ask why are you sticking around with old software *and* at
> > the
> > same time you try to build latest software (at least wget).
> Some users dislike the user interface changes Apple made in OS X 10.7 and
> later and stick with 10.6 by choice. Others have older computers incapable
> of running newer versions of OS X, or they believe the performance of their
> computer will be adversely affected by upgrading to newer versions of OS X.
> Nevertheless, they may wish to install software like wget that's not
> included with the OS.

Thanks for the insight.

> Requiring a newer pod2man is not terrible, and for users using a package
> manager is not an inconvenience if the package maintainer added the right
> dependencies. However, I don't disagree with Karl that including
> pre-generated manpages in the source tarball might be reasonable, just as
> it is reasonable to pre-generate the configure script and Makefiles. Also,
> I am in favor of configure-time checks for the capabilities you need. If
> you need pod2man to support --utf8, I would expect the configure script to
> check for that and bail with a helpful error message (e.g. recommending
> upgrading the perl installation), rather than failing at build time.

I didn't mean to completely disagree.
There seems to be no reason to reject a patch for a configure check (or a 
check in the Makefile.am itself).

And of course we can include the man pages (and other pre generated doc stuff) 
into the tarball.


Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]