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.
> 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.
> 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.
This is not the problem here yet, but will severely hinder the
flexibility of the codebase when such components are added (and they
will).
> 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.
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).
> > 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".
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.
> 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.
With best regards
Laslo
--
Laslo Hunhold <dev_AT_frign.de>
Received on Thu May 03 2018 - 10:01:52 CEST