[fpc-pascal] nested macros in C headers

Bernd prof7bit at googlemail.com
Sat Apr 23 22:50:10 CEST 2011


I found this:


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:
    VIDIOCGCAP          =   _IOR(Ord('v'), 1, SizeOf(video_capability));

in the above mentioned ten years old pascal file there is the following:

    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.

More information about the fpc-pascal mailing list