Re: [hackers] [slstatus] Revert component-split || Laslo Hunhold

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Thu, 3 May 2018 09:29:11 +0200

> Revert component-split

What the hell,

> After heavy consideration, the component split has more disadvantages
> than advantages, especially given there will be utility-functions
> sharing quite a lot of code that would then need to be duplicated, as it
> does not fit into the util.c due to its speciality.

I'm glad to know you had heavy consideration, but where did you discuss
about this?!
Maybe you forgot to discuss this with the interested parties?
You went again all FRIGN on suckless, forgetting this is a
grouped effort developing community and not a place where to dump your
“heavy considerations”.

You say “there will be disadvantages”, where are they?
For now you're just speculating on something not happened yet and
surely not verified.

There is no duplicated code at all (but a few includes, which isn't an
issue).

You're missing the point of compilation units.
You're just stuffing two completely different units into the same file,
sharing only the same filename. And the functions prototypes, which
you duplicate anyway.

No, this not eases reading at all, and worsen the structure of the
program.

> One big advantage of the component-wise build is readability, and
> without doubt, this was achieved here. This point will be addressed
> with a different approach that will be visible in the upcoming commits.

Again, speculating.
Why would this other untold approach be better?
Why is it not here now?

Are you talking about the next commit you made, indenting code under
#ifdef?
If this is not a joke, this is really bad and not worth of our
standards.

> One big disadvantage of the component build is the fact that it
> introduces state to the build process which is not necessary. Before its
> introduction, the only influencing factors where the system-defines
> __linux__ and __OpenBSD__. With the components, we are also relying on
> the output of uname(1).

This is not an issue at all.
If you don't like calling the POSIX tool uname, you can have as OS def
in config.mk.

> Additionally, if the os.mk is not present, make gives the output
>
> $ make
> Makefile:5: os.mk: No such file or directory
> make: *** No rule to make target 'os.mk'. Stop.
>
> This could easily be fixed by providing some sort of meta-rule for this
> file, however, it indicates the problem we have here, and this entire
> statefulness will heavily complicate packaging of this tool and makes
> the build process much more complex than it actually has to be.

Non-sense.
How is it complex to issue "./configure && make"?
Again, if calling a script is an issue, this can be adressed by the
solution in the previous paragraph, as you would have to edit it
anyway to add OS-dependant libs anyway (which the configure step
prevented to do).


In a shared open source project, decisions can and should be discussed.
You went again pushing your own agenda on other people's projects,
which is part of what harmed and still harms suckless as a community.
Received on Thu May 03 2018 - 09:29:11 CEST