Follow-up Comment #10, bug #66583 (group groff): At 2024-12-22T19:07:30-0500, anonymous wrote: > Follow-up Comment #9, bug #66583 (group groff): > [comment #8 comment #8:] >>> In any case, it seems you ran this with HAVE_MAKEINFO evaluating to >>> true. If that's the case, the conditional shouldn't change >>> anything; the result should be equivalent to the conditional line >>> not even being there. >> >> Did you try this scenario yourself? > > No;
You can stop that sentence there.
> I merely stated what is logical and works pretty much everywhere else.
s/what is logical/your assumptions/
Everywhere else? How many build systems have you mastered?
> It's not my fault that Autotools tend to defy logic.
It is when you're submitting a patch to an Autotools-using project.
>> I believe that _is_ in fact a defect introduced by your patch; the
>> mere surrounding of Make target rules with these conditionals _is_
>> the defect.
>>
>> I tried an alternate approach, indirecting the prerequisite file
>> names of the groff.{info,txt,html} files through Make macros, and
>> the build is quiescent in this respect now.
>
> It works just fine for me without those rules,
Without the _rules_? What I changed to fix your patch was the addition
of macro definitions, not the addition or removal of any rules (or
targets).
These are basic elements of make(1), not anything imposed by the GNU
Autotools.
Moreover, testing a change to a configuration system when multiple
configurations are possible is a poor defense of error or
incompleteness.
Recall Spencer & Collyer's "#ifdef Considered Harmful".
https://lists.gnu.org/archive/html/groff/2024-12/msg00002.html
It's okay to submit a patch that isn't completely baked or tested; what
is important is not to oversell or misrepresent that patch as more fully
baked and/or tested than it is.
> and I really don't get how surrounding something with a conditional
> that evaluates true can change its outcome. Sounds like a leaky
> abstraction (autoconf macro) is involved.
The earnest utterance of "leaky abstraction", like "layering violation",
is, to my eye, not a good look on anyone, just so you know.
https://lists.gnu.org/archive/html/groff/2022-09/msg00029.html
It's hard to take a charge of "leaky abstraction" clearly when one's
interlocutor isn't using the correct names for the relevant abstractions
in the first place.
Anyway, I've got the patch sorted out and tested on GNU/Linux/amd64 and
Solaris 10/SPARC, so you can look for it in my next push.
Thanks for the report.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
