[vlc-devel] Réf : Re: [PATCH] v4l2: check if kernel headers are recent enough

[Rémi Denis-Courmont]

Le jeudi 19 janvier 2012 20:42:24 Rafaël Carré, vous avez écrit :
> Le 2012-01-19 13:31, Rémi Denis-Courmont a écrit :
> > Le jeudi 19 janvier 2012 20:19:48 Rafaël Carré, vous avez écrit :
> >> Not supporting it doesn't mean try to build anyway.
> >> 
> >> We check if the C compiler is present but obviously we don't support the
> >> absence of it
> > 
> > Actually... configure does not fail if the C compiler is too old (try
> > gcc-3.2 or egcs for a laugh) even though the compilation will ultimately
> > fail in obscure ways. That is pretty much the same situation.
> 
> No since we can detect it.

Yes! We can detect both, and in fact do detect both. In both cases, a message 
is printed (the v4l2 plugin does warn that the headers seem too old).

> Le 2012-01-19 02:11, Rémi Denis-Courmont a écrit :
> > And
> > builders do ignore warnings. Next thing, they will come and complain that
> > v4l2:// stopped working silently. I'd rather have the build system
> > explode in their face really.
> 
> It can be changed to an error if we add an option to disable v4l2.

There is not much point in doing that. Bleeding-edge VLC git versions are not 
meant to be compiled with unsupported versions of libraries or systems. It is 
only natural that VLC drops support for stuff that upstream dropped already.

If you want to support your own fork of (an old version of) the Linux kernel, 
that is your problem. You are most welcome to support your own dedicated fork 
of VLC for that purpose. (It would seem more natural to stick with an old 
version of VLC but whatever.)

> Distros usually have recent kernel, so old distros with old kernels are
> likely to have more problems than just v4l2 and debian has a list of
> installed files so it would not go unnoticed.
> 
> > Furthermore I am not a fan of patching configure.ac as it is slow as
> > hell.
> 
> I agree that it is slow but this commit doesn't make it particularly
> slower.

The point is not that configure is slow. It is reasonable with caching 
enabled. It is build system churn that is annoyingly slow. I have spent quite 
some time to move logic to Makefiles to limit this.

This patch causes a full rebuild the build system just for a version check 
that belongs in the v4l2 access. Besides, this patch assumes that all v4l2 
plugins have the same version requirement. This is not true anymore with the 
output plugin.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis