[fpc-pascal] nested macros in C headers

[Sven Barth]

Hi!

I did convert the V4L2 headers some time ago, but did not publish them 
yet. If you want to, I can send you the Pascal file. I tested it with a 
radio tuner, so it should work mostly.

Regards,
Sven

On 23.04.2011 22:50, Bernd wrote:
> Hi,
>
> I found this:
>
> http://pastebin.com/T4jkeE6F
>
> in a zip file called vfp.tar.bz4 somewhere on the web, it seems not
> maintained since ages but obviously it must have compiled at some time
> in the past. I am tying to see whether I can hack a quick and dirty
> program that is able to open an v4l device and do some simple things
> and maybe grab a frame (if I can somehow manage to keep the motivation
> level above the frustration level for a long enough time).
>
> _IOR is defined as
>
> #define _IOR(x,y,t)     (IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)
>
> and in FPC I have found a *function* in kernelioctl.pp with the same
> name that seems to serve the same purpose, except that it is a
> function and not a macro.
>
>
>
> And here comes the problem:
>
> #define VIDIOCGCAP              _IOR('v',1,struct video_capability)
>   /* Get capabilities */
>
> obviously the following will not compile since the function cannot run
> at compile time:
> const
>      VIDIOCGCAP          =   _IOR(Ord('v'), 1, SizeOf(video_capability));
>
>
>
> in the above mentioned ten years old pascal file there is the following:
>
> //define[_IOR(][,#1,#2)][_IOC(2,ord('#0'),#1,sizeof(#2));]
> const
>      VIDIOCGCAP     = _IOR(v,1,video_capability);
>
> The first line looks like it is meant to be understood by some kind of
> prepocessor but FPC does not seem to understand this. The zip file
> also contains a folder with something that looks like it is a macro
> processor that is meant to be used to process this file and a makefile
> to start the entire thing but there are compile errors and and the
> perceived hack-level of this entire thing is quite high.
>
> What would be the most reasonable thing for me to have the handful of
> constants defined that I need (I don't need the entire API, only the
> most basic things to open my webcam and grab a frame¹). Should I use
> variables and initialize them at runtime? Or should I define functions
> instead of constants?
>
> How should I now proceed? Should I try to make this entire thing
> (including its macro pocessor) compile with a current FPC? I don't
> really like this idea because v4l1 is deprecated anyways. And the
> separate macro processor and the makefile also somehow does not look
> tlike the right approach to me, there must be a better way. And I
> don't need the entire full blown thing, only a small subset for a
> small quick and dirty program to try a little idea of mine (might
> prove to be throw-away code anyways).
>
> _____
> ¹) my current solution is just piping RGB data from streamer through a
> named pipe to my application, I just wanted to know if i could get rid
> of this external process and communicate directly with the camera and
> also be able to control gain and exposure directly and in real time,
> therefore I am investigating v4l/v4l2. I haven't found any other v4l
> implementation for FPC.