On 13:55 Wed 24 Feb 2010, Hans de Goede wrote: > On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote: > >Hans de Goede wrote: > >The better here is to have the latest kernel headers copied on the tree. > >This way, it is possible to compile libv4l2 with an older kernel version and > >later upgrade the kernel, if needed, or to use a fast machine to compile > >it, and then use it on another machine. > > > > If possible I would like to avoid this, afaik no other userspace > utility packages are doing this.
Off the top of my head I know ethtool does this. It greatly simplifies the work of maintaing the package: http://git.kernel.org/?p=network/ethtool/ethtool.git;a=blob;f=ethtool-copy.h;h=09dd5480ff3488214ab67ad04459541314291f79;hb=HEAD > Where necessary libv4l currently has code snippets like: > > #ifndef V4L2_PIX_FMT_SPCA501 > #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */ > #endif I don't think this is less work than copying the header file from the Kernel. Test building under all versions of the Kernel headers that exist to make sure something isn't missed isn't possible. It really is easier just to sync the header file up. > The reason for this is that I want to avoid carrying a copy of a dir > from some other tree, with all getting stale and needing sync all > the time issues that come with that, not to mention chicken and egg > problems in the case of new formats which simultaneously need to be > added to both libv4l and the kernel. Worst case is that if it is stale then it won't build since it depends on fancy new feature XYZ. But, at least it won't build on all systems instead of randomly breaking based on installed kernel headers version. > For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it > hits any official v4l-dvb kernel tree, with the: Please don't add features to releases before they are merged with Linus. It would suck to ship a copy of libv4l that has a different idea of structs or constants then the upstream Kernel. > Approach this works fine, if I were to carry an include tree copy, that would > now need to become a patched include tree copy, and with the next sync I then > need to ensure that any needed patches are either already in the sync source, > or applied again. Or just fix it upstream with #ifdef __KERNEL__ tags once and for all, right? Cheers, Brandon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
