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

Thomas Guillem thomas at gllm.fr
Mon Oct 7 09:38:09 CEST 2019


On Wed, Oct 2, 2019, at 18:13, Abdullah Alansari wrote:
> 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).

It's a very long but very fine post, no need to kick you for that ;)

Did you sent this mail following the discussion we had in https://mailman.videolan.org/pipermail/vlc-devel/2019-October/128041.html ?
In that case, you could have responded in this thread directly (for more context).

> 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.

Yes, that's what we want to avoid.

> 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.

I think our build documentation is not always up to date, and most of us are using debian. Maybe this could help some people using Fedora, thanks.


> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191007/2806ca4e/attachment.html>

More information about the vlc-devel mailing list