[vlc-devel] [PATCH] configure: fail on casting incompatible pointers

[Abdullah Alansari]

Hi everyone,

First and foremost, I just got into the mailing-list today and may just be
blabbing on and my understanding of the VLC project current state or
direction is way off. So if you're too busy just ignore the rest. However,
if you have some free time, please read on and sorry in advance for taking
so much of your time. I also understand if you kick me off this thread
(just say the word).

Silencing a single warning is fine in itself but what happens in reality is
that warnings are silenced once at a time until the number of silenced
warnings is bigger than what anyone would agrees to initially (even the
ones most asking for silencing the warnings).

On the other hand, adding warnings can be hard or just impractical for some
projects.

In addition, making the build process more lax/warning-tolerant is hard to
backup from and any decision that is hard to change shouldn't be taken
lightly.

Code review is not enough. Quite the opposite, what happens for many
projects with strong code-review is that a lot of code is waiting for
review and a major contributing factor is that reviewers spend a lot of
time discussing style and casting and stuff. So to resolve this they add
warnings and try to automate style-checks (and auto style-fixes) as much as
possible (including adding as many warnings as they can) to use the
reviewer's time only for stuff that no automation can do.

Some of these are a 1st-world problems. For example:
Styling and compiler warnings that can easily be added manifest most in
heavy code-review projects.
Change-detector tests, tests that require unnecessary changes when the
implementation change, manifest most in heavy test-automation projects.

There are also unconventional techniques (e.g: git-hooks to only run on
changed files) to gradually add warnings and such.

I think what makes these issues hard is they are in the far future and may
be many moves ahead.

This can also affect small projects by killing them because the cost to
work with existing code is too high and the cost to rewrite is non-trivial
too. A small project can also grow faster than expected with super
technical-dept.

I know the GNOME Web (epiphany) <https://gitlab.gnome.org/GNOME/epiphany>
use Gitlab's CI and fails a build if there's a single warning (not sure
what error-flags they have though) but the local build naturally doesn't
fail with warnings. I have experienced this first hand when a lib has just
added a new API and deprecated the old one at the same and the CI failed my
build for this:sweat_smile:. In general, I think GNOME Web can be used as a
reference for some cool building tools. I understand that VLC is another
ball-game (e.g: some dangerous warnings may need to be disabled in VLC
build).

As an aside when I was compiling VLC I had to do `./configure --disable-mpc
--disable-medialibrary --disable-opencv` but the Jenkins build was fine so
I suspect that the Jenkins/CI build doesn't cover some of the codebase and
can succeed even some stuff doesn't compile:sweat_smile:. I wrote a
mini-post on Compiling VLC on Fedora 29
<https://medium.com/@ahimta/compiling-vlc-from-source-on-fedora-29-387fdbf873bf>
if you're curious.

Links:
1. GNOME Web (epiphany): https://gitlab.gnome.org/GNOME/epiphany
2. Compiling VLC on Fedora 29 mini-post:
https://medium.com/@ahimta/compiling-vlc-from-source-on-fedora-29-387fdbf873bf

-- 
Abdullah Alansari,

LinkedIn: https://linkedin.com/in/ahimta
GitHub: https://github.com/Ahimta
Twitter: https://twitter.com/Ahymta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191002/4061f07e/attachment.html>