On Sun, Oct 16, 2022 at 01:24:03AM +0200, Laslo Hunhold wrote:
> 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.
>
100% is a lot.
> > 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.
>
This includes -DVERSION for example and you'd have to specify all flags,
including the paths for Freetype of X11 for example. Now it allows both options
more easily, respecting the default CFLAGS, LDFLAGS from the (build) system, or
overriding them completely with TABBED_CFLAGS, TABBED_LDFLAGS.
From what I've seen many Linux distros don't even change the CFLAGS or LDFLAGS
aslong as "it compiles, ship it". This would mean shipping with -Os and binary
stripping.
> 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 depends.
I'd generally prefer to avoid a configure script. It is hard to cover all
systems and forget some edge-case which makes configuring it on a system you
haven't thought about more cumbersome. Its one of the reasons GNU configure
scripts suck sometimes, because they try to cover all edge-cases and quirks,
but when the script fails it makes debugging it a lot harder.
I haven't looked into it deeply, but for example a quick glance in libgrapheme
I noticed it has a fallback case which just prints an error: "Your system does
not have a preset. Edit config.mk and send a patch please! :)".
Currently it looks not so bad, entirely optional(?) and a small script, but its
best to try to be too clever imho.
Like I said before I've seen some distros patch the config.mk or Makefile
instead of overriding the flags.
> 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.
>
It doesn't make it more cumbersome in this case. It might require a change
for current distros packaging it though.
> 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.
>
It is my goal aswell. Its fine if you don't agree. I've also distributed a
few small humble tools and looked at how packagers use them. Trying to make
packagers/porters lives easier.
"Trying is the first step to failure" I guess :P
> With best regards
>
> Laslo
>
--
Kind regards,
Hiltjo
Received on Sun Oct 16 2022 - 13:56:51 CEST