[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Build error in Devuan stable
From: |
G. Branden Robinson |
Subject: |
Re: Build error in Devuan stable |
Date: |
Sun, 1 Dec 2024 08:55:10 -0600 |
Hi Alex,
At 2024-12-01T15:03:12+0100, Alejandro Colomar wrote:
> Do you intend to fix this?
Trying out onf's patch is on my mental to-do list.
> Should I report a bug in Savannah?
Can't hurt to have it on a real to-do list as well.
However, we should distinguish cases:
> > > 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.
This is the part I mean to have a look at. It did on cursory inspection
seem much simpler than the frightful old doc/doc.am file (which remains
fairly intimidating).
[long quote follows]
> > 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?
I'm pretty disinclined to smash the set of Makefile targets in groff
into even smaller pieces than Automake already does.
What you suggest sounds like grafting an accessory build system onto
Automake, and that strikes me as a bad idea.
If people building groff have some need that Automake isn't fulfilling,
that issue needs to be raised first here, and if we can't figure out, we
can go to the Automake developers.
If they can't, or don't want to help, only then is it a good time, I
think, to start seriously contemplating forking or replacing the build
system.
The advantages of the system you propose seem pretty notional and
theoretical to me, as applied to groff. That doesn't mean they aren't
fine for other projects.
"For whatever reasons one may have" is a pregnant phrase. It is
laudable, even necessary, from a systems analysis perspective to be
capable, even eager, to decompose a system into mutually independent
facts. (If one were feeling nerdy, one might call this process "finding
an orthonormal basis for the configuration space".)
But when it comes to a configuration space in source code, I recommend a
review of Henry Spencer's paper "#ifdef Considered Harmful". I'm
attaching a copy.
I think similar principles apply to build configurations. The
difficulties get much worse if some configurations can't be exercised on
a certain environment. That slows down QA processes.
Regards,
Branden
ifdef Considered Harmful_Spencer.pdf
Description: ifdef_Considered_Harmful_Spencer.pdf
signature.asc
Description: PGP signature