Re: [hackers] [tabbed] Makefile improvements || Hiltjo Posthuma

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sun, 16 Oct 2022 17:51:04 +0200

On Sun, 16 Oct 2022 13:56:51 +0200
Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:

Dear Hiltjo,

> 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.

the risk is always there. I had a nice discussion with one Gentoo
packager who elaborated that they stay away from make -e for that
reason and rather pass the different make-variables as an array to make
it safer and easier to use.

To give one example why using the default variables is a good thing:
While packaging libgrapheme for homebrew, I noticed it automatically
passes the proper prefix and library-prefix to the makefile such that
it puts all the files in the proper directories, with 0 manual
configuration.

> 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.

Yep.

> 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.

I wasn't too fond of a configure script at first either, but that's
exactly the purpose of it: Provide defaults for known systems, fail on
unknown systems, always allow manual editing of the config.mk.

Most users are used to running ./configure && make install and with
just a few supported unames you cover 99% of today's systems easily.

> Like I said before I've seen some distros patch the config.mk or
> Makefile instead of overriding the flags.

Yes, me as well. This is often due to the widely-used GNUism "+="
which leads to many packagers not knowing that setting variables in the
command line overrides all internal macros.

> It doesn't make it more cumbersome in this case. It might require a
> change for current distros packaging it though.
>
> 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

We're also debating on a high level here. I'm deeply impressed what
packagers often go through to get software packaged and what developers
often do to really make their programs horrible to package. No matter
the nuances of using config.mk or not, I've always heard positive
feedback regarding all suckless software in terms of packagability.

With best regards

Laslo
Received on Sun Oct 16 2022 - 17:51:04 CEST