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: #ifdef NOT_GCC_4X #define MY_UNION u #else #define MY_UNION #endif union { } MY_UNION; 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. --HPSReceived on Wed Oct 08 2008 - 04:22:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC