[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Build error in Devuan stable
From: |
Alejandro Colomar |
Subject: |
Re: Build error in Devuan stable |
Date: |
Mon, 25 Nov 2024 00:36:46 +0100 |
Hi onf, Branden,
On Sun, Nov 24, 2024 at 11:43:57PM +0100, onf wrote:
> On Sun Nov 24, 2024 at 10:52 PM CET, Alejandro Colomar wrote:
> > I'm having a build error when trying to build groff HEAD in Devuan
> > stable. ./bootstrap and ./configure succeed, and them make(1) fails.
> > Below is the failure. Let me know if you need more details.
> >
> > [...]
> > GEN doc/groff.dvi
> > [...]
> > /usr/bin/texi2dvi: etex exited with bad status, quitting.
> > make: *** [Makefile:15737: doc/groff.dvi] Error 1
>
> As the output shows, this is a problem with building the Texinfo manual
> rather than with building groff itself. Unfortunately the current build
> process makes the manual inseparable from the program itself, so that
> if you can't build the manual, the entire build fails... which doesn't
> make a lot of sense since it's written in Texinfo, not troff, so its
> build failing means nothing in terms of groff's functionality.
>
> I recently suggested a patch which skips building the manual if makeinfo
> isn't present or is outdated.[1] You can easily modify it to disable
> building the manual even if it's present. Simply do this to the patch:
> s/(groff_have_makeinfo=)yes/\1no/
>
> and apply it. Re-running make should suffice according to the docs; if
> it doesn't, run the whole bootstrap > configure > make process again.
Thanks! +1 to your proposal.
Acked-by: Alejandro Colomar <alx@kernel.org>
Branden, you may want to have a look at the Linux man-pages build
system. I'm not proposing that you replace autotools with some
hand-written Makefiles, but the way the dependencies are laid out are
interesting. You can run `make` (a.k.a., `make build`) which runs all
default targets. In the man-pages project it only stamps the page date
and project version into each page. In other projects of mine (liba2i),
it builds the library shared object (.so).
But then I allow building less than that with specialized `make build-*`
targets:
$ make help
To see a list of targets, run:
$ make nothing -p \
| grep '^\.PHONY:' \
| tr ' ' '\n' \
| grep -v '^\.PHONY:' \
| sort;
To see a list of variables, run:
$ find GNUmakefile share/mk/configure -type f \
| sort \
| xargs grep '^[^[:space:]].*=' \
| sed 's/=.*/=/' \
| grep -v -e ':DEFAULT_.*=' -e ':MAKEFILE_.*INCLUDED :=';
To see a list of dependencies (package/program), run:
$ find share/mk/configure/build-depends -type f \
| sed 's,share/mk/configure/build-depends/,,' \
| sed 's,\.mk,,' \
| sort;
$ make nothing -p \
| grep '^\.PHONY:' \
| tr ' ' '\n' \
| grep -v '^\.PHONY:' \
| sort \
| grep ^build;
build
build-all
build-catman
build-catman-eqn
build-catman-grotty
build-catman-troff
build-catman-troff-man
build-catman-troff-mdoc
build-ex
build-ex-cc
build-ex-dir
build-ex-ld
build-ex-src
build-fonts
build-fonts-download
build-fonts-tinos
build-html
build-html-post-grohtml
build-html-troff
build-html-troff-man
build-html-troff-mdoc
build-man
build-man-man
build-man-mdoc
build-man-so
build-pdf
build-pdf-book
build-pdf-pages
build-pdf-pages-eqn
build-pdf-pages-gropdf
build-pdf-pages-troff
build-pdf-pages-troff-man
build-pdf-pages-troff-mdoc
build-pre
build-pre-preconv
build-pre-tbl
build-ps
build-ps-eqn
build-ps-grops
build-ps-troff
build-ps-troff-man
build-ps-troff-mdoc
And have similar install-* targets:
$ make nothing -p \
| grep '^\.PHONY:' \
| tr ' ' '\n' \
| grep -v '^\.PHONY:' \
| sort \
| grep ^install;
install
install-all
install-bin
install-html
install-man
install-man1
install-man2
install-man2const
install-man2type
install-man3
install-man3const
install-man3head
install-man3type
install-man4
install-man5
install-man6
install-man7
install-man8
install-manintro
install-pdf
install-pdf-book
This allows you to build parts of the project without needing to build
the entire project, for whatever reasons one may have.
In groff, I would propose at least separating into build-bin and
build-doc, and then do similarly for the install targets. Also, please
provide a `make help` that documents whatever organization you come up
with (or in some README, or wherever you find appropriate).
Does that sound good to you?
Have a lovely day!
Alex
> ~ onf
>
> [1] https://lists.gnu.org/archive/html/groff/2024-11/msg00165.html
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature