Follow-up Comment #9, bug #66583 (group groff): [rearranging]
[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; I merely stated what is logical and works pretty much everywhere else.
It's not my fault that Autotools tend to defy logic.
>> Looking at the affected area of doc/doc.am, there is not a single
>> thing within the conditional that is not info-related; in fact the
>> entire area is introduced by a long comment beggining with
>>
>> # groff Texinfo manual
>
> Right. But there is a difference between macro definitions and target
> rules.
[...]
>> [comment #6 comment #6:]
>> [...] That is not a defect introduced by my
>> patch, though; I merely surrounded those rules in doc/doc.am with a
>> conditional.
>
> 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, 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.
~ onf
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
