Follow-up Comment #27, bug #66583 (group groff): [comment #25 comment #25:] > [comment #24 comment #24:] >> [comment #23 comment #23:] >>> https://savannah.gnu.org/bugs/?66609 does exactly that. The only issue it >>> has is that I'm not sure how should manually disabling building the manual >>> be reflected in the summary of available features that ./configure prints. >>> The current state is that it prints:
>>> can build groff.{info,html,txt} : no
>>> can build groff.{dvi,pdf} : no
>>> as if makeinfo wasn't available. I am not sure whether this is correct
>>> behavior.
>>
>> Allow me to correct myself. It doesn't do even the above. It prints:
>> can build groff.{info,html,txt} : yes
>> but then doesn't build them anyway, which feels wrong. Either we could
>> simply print "no", or we could print something like "disabled" to clearly
>> distinguish it from makeinfo not being available, although it could be
>> argued that omission of the related warning is precisely such a
>> distinction,
>> though.
>
> If we're talking about what's actually been committed to Git, I can't
> reproduce this.
>
> [...]
No, I was talking about the behavior of my suggested patch. I suggest you
read
the part of comment #23 you quoted above again.
>> It prints:
>> can build groff.{info,html,txt} : yes
>> but then doesn't build them anyway, which feels wrong.
>
> The auxiliary verb "can" is not a synonym of "will". If you build from a
> distribution archive, which is *the* premier means of _groff_ distribution,
> the generated forms of our Texinfo manual are already present, and therefore
> would only need to be regenerated if someone modified _doc/groff.texi_.
>
> Are you familiar with the practice of distributing (compressed) tar archives
> when making a software release?
Mostly theoretically, but I am aware it's a method used to package releases
for distribution.
Since I was talking about the behavior of my patch, what I was talking about
is that the
"can" signifies the system has that ability, but the generated Makefile
actually cannot
build it even if you deleted the generated documentation. I admit that after
reading further
comments by Alex, the approach I've used to implement this doesn't seem
particularly good.
[comment #26 comment #26:]
> At 2024-12-28T16:04:10-0500, anonymous wrote:
>> Follow-up Comment #23, bug #66583 (group groff):
>> [comment #21 comment #21:]
>>>> Follow-up Comment #15, bug #66583 (group groff):
>>>> I doubt it will, because in his case, ./configure evaluated
>>>> makeinfo as present & up-to-date,
>>>
>>> Either I'm confused, or you mean not "makeinfo", but one or more of
>>> the artifacts that "makeinfo" produces (groff.info, groff.html, and
>>> groff.txt), the first two of which are only a subset of artifacts
>>> produced since these formats involve multiple output files).
>>
>> I meant the program itself; outdated versions of makeinfo are treated
>> as missing.
>
> Ah. "Up-to-date" is also a term of art when discussing the operation of
> make(1).
Yes; I failed to find a better word to describe the concept of makeinfo>=5.0.
> [...]
>> The problem Alex was experiencing, though, occured with a version
>> which groff accepted.
>
> Okay, well, he should be getting CCed on this so maybe he can put us in
> the picture.
I agree, but you're saying that to the wrong person. You know that users
without account don't have permission to do that, don't you?
> [...]
>
> The repository, and the distribution archives, are written with default
> make targets selected in the expectation of a relatively unsophisticated
> user who hasn't mastered all the parts of the groff system and simply
> wants "all the usual stuff". The "usual stuff" avowedly includes
> documentation of the system in question. This is standard practice in
> Unix software release management and has been for decades.
Unfortunately, it seems these "default make targets" don't include the
standard bin target.
>> or build docs.
>> I really dislike this approach of "we're smarter than the user".
>
> In contrast, I really dislike an approach of playing guessing games with
> one user who wants to remold groff's build system to adopt his personal
> preferences as new defaults.
If you think these are my preferences, you must have missed how annoyed
autotools make me, or the remark about this possibly not being a good
patch, just one matching my ability (with autotools).
> Why are you riding on the tip of groff's master branch if you're not
> interested in whether it works as an integrated whole?
I would argue the Texinfo manual has nothing to do with groff (not)
working as an "integrated whole".
>> I know it does, the difficulty for me was in disabling the rest of the
>> docs without affecting gnu.eps. That issue has been solved now.
>
> An alternative approach that might suit you is to simply stop running
> "make" without any arguments. If your area of interest is narrowly
> focused, say that. Not (just) to me, but _to the system_. [...]
Fair point; the addition of a bin target seems in retrospect as a
better way to go about this.
> [...]
>> That is also why these patches are adding flags to ./configure instead
>> of adding make targets (which would be the correct approach, but at
>> least an order of magnitude more complicated with autotools).
>
> Or, as noted above, you could just ask `make` for the targets you care
> about, instead of elaborating the build system so that you never have to
> give that command any arguments.
Point taken.
> [...]
>>> Since the people who don't want to build the documentation are also
>>> unlikely to ever contribute patches to it, perhaps the best solution
>>> to is to concretely manifest one's contempt for documentation with
>>> "git rm doc/groff.texi".
>>
>> ...only after obtaining doc/groff.* from elsewhere...
>
> Or not making "all"...
As noted above, there is no target to build all the binaries without docs.
> [...]
>> and (2) automake conditionals weren't broken.
>
> I'd wager that the Automake developers aren't complete idiots, and that
> there is a good reason for them to not govern make(1) targets.
>
> I would characterize my own solution...
>
> diff --git a/doc/doc.am b/doc/doc.am
> index 625f9cace..a4f0df6cf 100644
> --- a/doc/doc.am
> +++ b/doc/doc.am
> @@ -542,13 +542,18 @@ endif
> #info_TEXINFOS = doc/groff.texi
> #doc_groff_TEXINFOS = doc/fdl.texi
>
> +if HAVE_MAKEINFO
> +GROFF_INFO = doc/groff.info
> +GROFF_TXT = doc/groff.txt
> +GROFF_HTML = doc/groff.html
> +endif
> +
> if USE_TEX
> GROFF_DVI = doc/groff.dvi
> GROFF_PDF = doc/groff.pdf
> -endif
> +endif # USE_TEX
>
> -all: doc/groff.info doc/groff.txt doc/groff.html \
> - $(GROFF_DVI) $(GROFF_PDF)
> +all: $(GROFF_INFO) $(GROFF_TXT) $(GROFF_HTML) $(GROFF_DVI) $(GROFF_PDF)
>
> # Distribute the manual in source form as well.
> EXTRA_DIST += doc/groff.texi.in doc/groff.texi doc/fdl.texi
>
> ...as straightforward, but I dare not say idiomatic.
It stops being straightforward when you want to disable the entire
contents of doc/doc.am.
> Having had to deal with cmake, I'm firmly convinced that it lacks
> greener grass.
I never suggested cmake as a replacement; if anything, I suggested
using a simple hand-written configure would likely be easier to work
with. I am not saying groff should switch to that, though.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
