On Thu, 3 May 2018 10:26:56 +0200
Quentin Rameau <quinq_AT_fifth.space> wrote:
Dear Quentin,
> Yeah well, if you mean W3C as in it pushes harmful things while
> meating in secret, maybe. ;p
touché! :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!
Then we obviously have a different understanding of this notion, which
is fine per sé.
> 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?
The simple reason is that one shouldn't make software unnecessarily
complex. The side-effects of the component split though hit the package
managers the most, which is why I mentioned them here.
> 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.
Yes, the point is another one. I want to stress here that there is no
perfect solution and every solution comes with advantages and
disadvantages. Which solution prevails in this sense is also dependent
on where you measure things, and there is no right or wrong in this
regard.
> Where is this code?
> The current evolution of this project clearly showed that this isn't
> the case.
The evolution of the apes didn't show until a (relatively) few years
ago where it would lead. It's wrong to overgeneralize a program, but
it's not wrong to stay "flexible".
And I can think of multiple examples, where that might be the case,
especially when the parsing becomes more elaborate for some functions.
> > 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.
This is a misunderstanding. I was talking about the code before the
split. Obviously the split solved this problem very well! :)
> 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.
I cannot predict the future, but such side-effects can give you
trouble, that's it.
> 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.
This is true! :)
> 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 did not revert anybody's code, but suggested an alternative solution
to a problem which was easier to reach by reverting the previous
solution beforehand.
> I think we can now close the matter, this is done, fine.
> Just try to prevent such attitude in the future.
I don't see this as a form of attitude, but given I heard this wish for
more general discussion, I very much welcome discussing such changes in
the broader scope in the future.
With best regards
Laslo
--
Laslo Hunhold <dev_AT_frign.de>
Received on Thu May 03 2018 - 11:06:25 CEST