bug-groff
[Top][All Lists]
Advanced

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

[bug #66583] [PATCH] allow building groff without makeinfo


From: anonymous
Subject: [bug #66583] [PATCH] allow building groff without makeinfo
Date: Fri, 27 Dec 2024 19:23:56 -0500 (EST)

Follow-up Comment #15, bug #66583 (group groff):

[comment #13 comment #13:]
> Alex, does this fix address the problem you reported to the email list in the
> "Build error in Devuan stable" thread (linked in comment #4 and comment #5
> here)?

I doubt it will, because in his case, ./configure evaluated makeinfo as
present & up-to-date, and only the subsequent build failed. My patch merely
addresses cases where one doesn't have (up-to-date) makeinfo. Note that in the
message I linked, I instructed him to manually modify the patch.

I have an expanded version locally which adds flag to ./configure to not build
the Texinfo manual even when makeinfo is present & up-to-date. I haven't
posted it yet because I deemed it incomplete. It deals only with the Texinfo
manual and not with the rest of the docs, which might also be desired. I had
hoped that Branden would assist me in disentangling the gnu.eps file from the
rest of documentation, which would allow me to extend this to the entire docs.
Alas, it seems he doesn't get the desirability of such changes, let alone the
idiocy of the current setup, so I am sending the patch to the mailing list in
case someone finds it useful.

With the patch, one can run ./configure --disable-info-doc to skip building
the Texinfo manual, which is what Alex needed before.

> [comment #5 comment #5:]
>> which is a separate thread in the archive (presumably due to
>> his client omitting the In-Reply-To: header)
> 
> It's actually a limitation of the email list's archiving software, which
> limits every thread to a single calendar month.  In email, this thread
> spanned two calendar months, so it's archived as two threads.

I see, my bad.

[comment #14 comment #14:]
> Regarding the patch itself, I don't like it.  I'm not saying it's not the
> right patch (I don't know autotools, so can't judge that).  I just mean that
> if it's the right thing, it tells me that autotools is brain damaged.  Why do
> you need to test for the existence of a tool that builds documentation for
> being able to build a binary?  The right fix in a sane build system should be
> to fix the depencencies so that compilation of the binary and compilation of
> the documentation happen in parallel, and one can succeed without the other.

To be honest, I am not sure it's the right patch; it's just the one that
matched my abilities. If anyone is capable of fixing this properly, it's
Branden, but he doesn't seem very eager to do it.

The problematic part is doc/gnu.eps. The instructions for building it are
specified in doc/doc.am alongside other documentation, but the file itself is
included by tests as well. I have tried extracting the instructions related to
it into a separate file, but it didn't work correctly. I will try looking into
it again and try to make it work.

> Anyway, I'll try it soon.  Thanks!

I'm not sure if I said it before, so I will say it now: thanks, Branden, for
improving the patch with your expertise, and for merging it.

~ onf


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66583>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature


reply via email to

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