This is a discussion on Re: Video4Linux header files - FreeBSD ; On Saturday 19 May 2007, Luigi Rizzo wrote: > On Sat, May 19, 2007 at 11:24:34PM +0200, Hans Petter Selasky wrote: > > On Saturday 19 May 2007 21:14, Luigi Rizzo wrote: > > ... > > > > - ...
On Saturday 19 May 2007, Luigi Rizzo wrote:
> On Sat, May 19, 2007 at 11:24:34PM +0200, Hans Petter Selasky wrote:
> > On Saturday 19 May 2007 21:14, Luigi Rizzo wrote:
> > > - i don't know how problematic is this, but v4l2 headers seem to use
> > > unnamed unions which, last time i tried, conflict with the compiler
> > > setting used to build the kernel. While this is possibly an
> > > orthogonal problem which we may have to address at some point (as
> > > unnamed unions seem to be a common paradigm in linux headers), it is
> > > yet another hurdle.
> > Unnamed unions are not so good. I suggest that we terminate unnamed
> > unions with an "u".
We can make this a compile time option:
#define MY_UNION u
I see no problem about that. Else it will be a nightmare to port the code to
other and especially older compilers.
> It is not our choice. Linux v4l2 headers use these unions,
> software is written against these headers, we can't change the
> names unless we want to make extensive changes to the sources.
We can be compatible with both!
> > > I suppose a suitable plan would be the following, but i have not had
> > > the time to work on it:
> > >
> > > 1. add a v4lcompat build-dependency on the ports potentially affected,
> > > making sure they still build correctly using v4l1
> > > 2. add v4l1 headers in the base system (possibly changing the v4lcompat
> > > port to not install the headers if they are already in the base
> > > system);
> > I want to put a V4L2.0 "videodev.h" under /usr/src/sys/sys/ with some
> > modifications. What do you think about that?
> All the constraints i mentioned in the original email still apply.
> First you need to address the unnamed unions problem, then
> you will have to deal with a significant amount of breakage in
> the ports.
See comment above.
> > > 3. modify the vl4compat port to add the v4l2 headers, again fixing
> > > any breakage in the builds
> > > 4. as in step 2, add the v4l2 headers to the system, changing v4lcompat
> > > as needed where the v4l* headers are in the base OS
> > Does anyone know which ports use the current Linux compat layer port and
> > the v4lcompat port ?
> There is some magic port script you can run on the ports tree to get the
> list of ports which depend on v4lcompat. But the problem, as i tried to
> explain in the original message, is that there are ports which don't have a
> v4lcompat dependency while they should (at least to have a
> consistent build environment) and others which misbehave when they find
> a v4l header.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"