Re: [dev] lightweight build system

From: ochern <dexahex_AT_gmail.com>
Date: Thu, 27 Jul 2017 03:37:31 +0300

S. Gilles and you have pointed same negative property of sh -
readability. I agree that plane mk is good enough for static or almost
static configurations. Say I need to pass some -D flags according to
configuration/environment and such defines are meaningful and needed
only in current sub-module. I have two approaches
1 Set flags globally in toplevel config.mk
2 Set flags locally using some Make extension for conditional syntax.

Approach 1 is just incorrect. Any sub-directory specific set up should
not be global.
Approach 2 is not standard so, IMHO, it sucks by default. I don't want
to learn/use different GNU ifeq or other extensions and add additional
dependency on a non-standard tool

> Generating Makefiles obscures the simple cognitive task of adjusting a
> correct path by some weird shell script logic that one needs to
> understand as well. It is the whole argument against GNU autohell,
> that generating build files is insane.

I agree about GNU autohell. But I mean something different when
talking about Makefile generation.
gnu automake sucks because it adds another layer over make. Compared
to it GNU extensions suck even less as self-contained implementation.

Saying about makefile generation I mean writing Makefile inside Sh
same as writing awk or sed inside Sh. Of course we can write separate
sed or awk script. But mostly they are used as part of Sh program,
right? Yes it's rather rude comparison since we do not run make from
Sh but really generate makefile. Anyway we write in pure Make in pure
Sh. I have given an example. I've mentioned that Sh can be used in
toplevel configuration part, when needed. Treat it as a simple and
rather evident solution to "extend" standard Make. But "extension" is
not a right term. We don't argue about 'sed' deficiencies when besides
editing we need to find and check filesbefore. We use Sh for this and
sed as part of Sh script. We don't think about starting a new project
of "better" Sed with new wow-features that allow to search and test
files, right?

A common mistake of many developers is when they try to bring shell
inside program instead of brinning program in shell.

> You need to learn and
> understand 2-3 languages (shell, m4, weird GNU make, log output) to
> track down issues with it, whereas you only need to learn and
> understand make in a decent world.

I wouldn't put Sh in common group of languages in sense to learn it or
not. As far as it's standard and is extremely simple I consider it a
must-know by every developer at least at a beginning level. Sh has too
much flaws to be a common language, same as pure Make - as a universal
build tool. Whenever you make a "better" Sh you generate new Perl,
Python, TCL .. XXX. And than people say 'XXX Rules!/Sucks!'. But pure
Sh doesn't suck because it's really simple and good enough for simple
admin/config tasks. Just don't use it for complex programs, for which
Sh was not designed for. Simple is beautiful. Same with Make. You
extend it and produce another freak. In the same manner we could think
about extending Sh towards Make :).

> Also options suck. They are a sign of indecisiveness or weakness in
> finding proper defaults or making firm UI decisions.
> I want tools that work out of the box without bothering about
> "configuration". We can waste a lot of time with "configuring" to
> death.

When you run './configure' without options it generates
config.mk/config.h with defaults. At the same time it provides options
that allow to change some defaults. Of course there can be two screens
of options. Developer must have a good sense otherwise it will produce
shitty bloatware no matter what tool/language he uses.
Over-engineering is a common disease.

> I get the parser of C
> already in the compiler and does not need to reinvent a language
> parser for "options".

I agree. There is CPP and config.h is reasonably good and sufficient.

Regards.
Alex

On Wed, Jul 26, 2017 at 11:29 AM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 26 July 2017 at 03:28, ochern <dexahex_AT_gmail.com> wrote:
>> That's right. No new build system is suggested.
>>
>> Let me suggest a small poll:
>> 1 What build systems do you consider as most suckless?
>
> Plain mkfiles + rc or plain Makefile's + sh and sbase-compliant command usage.
>
>> 2 Generating Makefile from a shell script: it sucks, it's acceptable
>> or it's rather suckless?
>
> It sucks. There is no need to generate Makefiles. I prefer the
> suckless approach of config.mk's for adjusting include/lib lookups on
> excotic platforms, whilst using defaults that work on almost every
> platform. I'm also a strong opponent of using pkg-config crap. I hate
> it and I prefer to delete it whenever I see it.
>
> Also in terms of code, it appears to be incompetency among several
> developers that require platform specific defines on Linux/BSDs --
> they are barely necessary. Windows etc. is out of scope for this
> community.
>
> Generating Makefiles obscures the simple cognitive task of adjusting a
> correct path by some weird shell script logic that one needs to
> understand as well. It is the whole argument against GNU autohell,
> that generating build files is insane. You need to learn and
> understand 2-3 languages (shell, m4, weird GNU make, log output) to
> track down issues with it, whereas you only need to learn and
> understand make in a decent world.
>
> The same argument also applies to the discussion config.h vs config
> file parser. Why should I learn a config file language, if I can
> achieve the same with the programming language? I get the parser of C
> already in the compiler and does not need to reinvent a language
> parser for "options".
>
> Also options suck. They are a sign of indecisiveness or weakness in
> finding proper defaults or making firm UI decisions.
> I want tools that work out of the box without bothering about
> "configuration". We can waste a lot of time with "configuring" to
> death.
>
> All this is rather obvious to me.
>
> BR,
> Anselm
>
Received on Thu Jul 27 2017 - 02:37:31 CEST