On Fri, 14 Oct 2022 20:08:11 +0200
Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
Dear Hiltjo,
> Yes, but things can change,
>
> Some rationale of the changes are described here:
>
> gopher://bitreich.org/1/scm/bitreich-style/file/c/makefile-guideline.txt.gph
>
> For example suppressing output (with _AT_) which adds a small obstacle
> for debugging the build process has always been a nuisance. The build
> process should be as transparent as possible imho. This also removes
> the need of the old "options" target.
yes, I agree 100% there.
> Another thing we should adapt in my opinion is changing the way
> CFLAGS, LDFLAGS and CPPFLAGS are set so packagers/porters can set the
> build environment more easily. Hardcoding certain flags and
> optimizations are a nuisance. Currently some distributions also
> patch config.mk, which is bad imho. There are also more subtle
> flags, like compiler hardening flags which won't always work (it
> requires a particular order).
How can it be simpler than calling
make CFLAGS=... LDFLAGS=... CPPFLAGS=...
? No matter what you put into config.mk, explicitly specified variables
in the make command-line override it.
Judging from the experience I had with getting farbfeld and libgrapheme
packaged in multiple distros, respecting the "default" variables,
offering a config.mk and a minimal sh-based ./configure to
automatically modify config.mk with system defaults is the best of both
worlds.
It allows easy packaging but also allows users running off git-HEAD to
modify the build without having to modify the Makefile (which becomes
necessary when the config-flags are there). Swapping out build-contexts
is also trivial, which I often do and can by simply switching the
config.mk. If you have changes in the Makefile underway, which happens
especially during development, this becomes more complicated.
So even though only offering a Makefile won't harm packagability, it
will make it more cumbersome to work with in general.
In the end, it's the maintainer's choice of course, but making software
easier to compile and install makes it more likely that people will use
and test it and file bugs with patches.
With best regards
Laslo
Received on Sun Oct 16 2022 - 01:24:03 CEST