groff
[Top][All Lists]
Advanced

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

Re: [groff] 15/39: [grog]: Drop relic code and comments.


From: Dave Kemper
Subject: Re: [groff] 15/39: [grog]: Drop relic code and comments.
Date: Tue, 1 Nov 2022 00:08:06 -0500

On 10/31/22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> At 2022-10-30T23:41:43-0500, Dave Kemper wrote:
>> I'm less convinced by this -- unless a difficult roadblock stands in
>> the way, I think modern groff ought to work or fail gracefully on an
>> obsolete platform -- but the prior two points are convincing enough on
>> their own.
>
> I broadly sympathize with this but I find it a matter of tradeoffs.

Yes, I should have clarified that I see this as a general ideal that
often has to bow to the real world.  I basically agree with all your
caveats and tradeoffs.

> I don't see a lot of value in bending over backwards to
> accommodate versions of the language that the vast majority of its own
> practitioners no longer embrace.

Agreed.  I didn't see a one-line "require" as bending over backwards,
but since you pointed out that the version it specified was little
better than a wild guess, I agree it's inappropriate to retain it.

And it's less about accommodating older versions than it is telling
the user "we don't support that version."  But as you also point out,
the build already does that.

> Is it worth the trouble to implement
> some mechanism for including "require" (or "use") statements only for
> production builds?

I can't answer whether it's worth the trouble, but Perl is happy to
let you wrap a "require" line in an "if" block (or, more perl
idiomatically: "require v5.6 if cond;").  I don't know the
build/install system well enough to know what the condition would be.
Any shell environment variable is available to perl via the ENV{}
hash, so if one of those has the info you need, the implementation is
fairly trivial.



reply via email to

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