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

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Thu, 3 May 2018 10:26:56 +0200

On Thu, 3 May 2018 10:01:52 +0200
Laslo Hunhold <dev_AT_frign.de> wrote:

> On Thu, 3 May 2018 09:29:11 +0200
> Quentin Rameau <quinq_AT_fifth.space> wrote:
>
> Dear Quentin,
>
> > 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”.
>
> what is this? The W3C? I won't have to remind you that you were one of
> the most vocal supporters of the maintainer-supremacy, i.e. that the
> maintainer always has the last word in these matters, and Aaron made
> the choice to include my patch rather than continue on with the
> component split.

Yeah well, if you mean W3C as in it pushes harmful things while meating
in secret, maybe. ;p
I'm not sure where you saw me being a “most vocal” supporter of
“maintainer-supremacy”, because that's not true.
Yes, the maintainer of a project makes final decisions… After they have
been discussed!

> > You say “there will be disadvantages”, where are they?
> > For now you're just speculating on something not happened yet and
> > surely not verified.
>
> I sourced this speculation from my experiences with software packagers.

Impressive, still very unclear, why would a software packager (who
pleasing wouldn't be our primary objective when writing software
anyway) care about the internal structure of a software, when his entry
point is only issue two or three make commands?

And if you're going that way, issuing a ./configure (which I'm
necesseraly wanting to push there) is clearly more handy than editing a
couple of lines in a file.

But that's not the point.

> > 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.
>
> This stops working well when you have a component for Linux and
> OpenBSD that is pretty much common among the systems, but still relies
> on a common utility function. If you end up splitting them up into two
> files, you either have to move this utility function to util.c (which
> doesn't make sense in 99% of the cases) or duplicate it in both files.

Where is this code?
The current evolution of this project clearly showed that this isn't
the case.

> This is not the problem here yet, but will severely hinder the
> flexibility of the codebase when such components are added (and they
> will).

Possibly. That's not the actual case.

> > 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.
>
> Maybe I wasn't clear here. The problem that lead to the component
> split-up was that the ifdef-tree made the code less readable. The split
> achieved to increase readability (which I honored here), but sadly not
> for all files. We still had files with ifdef-trees and it wasn't easy
> to compare two "implementations" as you had to scroll through two files
> at the same time.

No you're inventing things here, there was no such ifdef-trees files as
you state, as they have been splitted.
The only remaning couple if-def are for includes in files sharing the
same code disregarding of the OS.

> It was rather inconsistent that one still had these separate components
> as one structure-idiom and then still single files.
>
> > 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.
>
> Glad we came to the core of this. Why is it not worth our standards? I
> know that in pre-ANSI ages, you were not allowed to indent compiler
> imperatives (#include, #ifdef, ...). C99 allows this.
>
> Granted, it's not a form you commonly see and it has disadvantages
> (e.g. it breaks some peoples' workflow for finding function
> declarations).

Because it adds an unnecessary indentation level.
Because it doesn't ease readability.
Because that's a bad idea.

> > > 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).
>
> This is the fundamental issue with this component approach. The make
> output gives no indication what the user has done wrong and he has to
> pretty much scan the folder and see the "configure" script and figure
> out that this is what generates "os.mk".

Yes, big issue.
Also, he had to read the README which indicates that it's a step to
take.
Who has the time to read READMEs anyway? Such a burden!

As I repeated, the configure can be replaced with a macro in config.mk.

As a sidenote, the configure step could be easily automatised in the
Makefile, most common make implementations supports it, but it's not in
POSIX yet (will be in the next release).
And as I, unlike you, don't speculate too much on what possibly could
happen at some undetermined time in the future, I didn't put it there
yet.

> The big issue is, and that's what I meant with the commit, that only
> supporting Linux and OpenBSD, you can rely on preprocessor definitions
> (__linux__ and __OpenBSD__). With the split component approach, you end
> up introducing state like uname(1), which not necessary at all.

You could also stuff all code in one file, as the current Makefile
builds all the components anyway, separating components is not
“necessary” at all either.
Still, this is clearly better code organization.

> > 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.
>
> I have made mistakes in the past, but this was just a suggestion and
> Aaron as a maintainer chose to commit it. I didn't force anything on
> anybody. As I stated above, the maintainer has the last say in these
> matters.

Yes, but the fact that you didn't even think about discussing this
change reverting somebody else's code with others clearly states
(again) your methods.

You can see this doesn't happen with other coders, strangely.

I think we can now close the matter, this is done, fine.

Just try to prevent such attitude in the future.
Received on Thu May 03 2018 - 10:26:56 CEST