[vlc-devel] [vlc-commits] include: work around LLVM brain damage
remi at remlab.net
Mon Feb 27 22:58:25 CET 2017
Le maanantaina 27. helmikuuta 2017, 22.20.00 EET Marvin Scholz a écrit :
> > Oh the hypocrisy. Oh the ingratitude. That change is a trivial
> > stopgap to
> > make the build logs readable for people like you using LLVM.
> I never said that I consider this patch wrong, I was just pointing out
> that it would have been more friendly,
Look, either the patch was merged or it was not. If it was not, then LLVM
users (including you) cannot read the build logs. I don´t think waiting for an
agreement (which might not come any time soon) is practical. And the potential
merge conflict from a one-liner is trivial to fix.
> in regard to the ongoing discussion
> topic, to send it to the ML and maybe point out that you only intend it
> a temporary solution until a better one is found.
Oh come on. The patch description started with "work around".
> Whenever someone breaks the build you complain and nearly immediately
> revert, or even force- push the changes away. It is not like people break
> the build just to annoy you, you know?
If the code does ostensibly not pass the test suite on any target, then it is
fair game for revert. This applies to my code too. And my code is the code
that I most frequently force push and/or revert.
> On top of that, you break the build frequently too.
And what do you expect? That I complain to my own self on the mailing list?
When I break the build, either I notice quickly and rectify, or I don´t know
and somebody else fixes/reverts it.
Also, there is no such thing as a "the build". I held my last "major" build
system change (skins2 derecursion) from push for two weeks because I did not
have access to proper computer to validate it... And yes, the initial version
did turn out to break the build.
Not that you´d notice unless you compare the commit and push timestamps.
> In the last case I remember, even knowingly with your tls module
So I broke a platform-specific important but non-essential plugin for a
proprietary library and with an obvious fix on a single platform. JB and your
changes rendered VLC not debuggable on any platform and with no obvious fixes
other than revert. That´s really not the same level.
Besides, the TLS module exists only because Gildas did not want to link LibVLC
(nowadays libvlccore) to GnuTLS directly. The goal was _never_ to allow
alternative backends. And indeed, to this day, there exists no other proper
alternative since the ST plugin does not fully implement the API.
I think I did warn that adding another backend would cause problems if I
cannot test it. Indeed, many honest attempts to update it failed. Thing is,
AFAIR, David and Felix took responsibility for following up when ST was
merged. I would never agree to merge ST if I´d had to maintain it myself.
This will continue until/unless somebody documents a reasonable way to
validate changes offline on an OSS development environement.
And that you were not part of the project at the time when ST was merged is
not an excuse for lashing out at people. I have never committed to whatever
you want the TLS change policy to be, and I won´t for the foreseeable future.
> Even though it only affected macOS, it was annoying and unnecessary.
First, this is self-inflicted pain for using a platform-specific plugin. And
second, the change was necessary.
> You could have sent the patches to the ML and asked one of the macOS devs to
> fix the ST module to work with your changes, in case you do not want/can't
> easily do the necessary changes yourself.
Sending patches to the ML does not magically spawn patches. And even if it
did, it wouldn´t avoid incremental build breaks.
More information about the vlc-devel