These files add kqueue to the FreeBSD rtl. the new "FreeBSD.pas" file will need to be put in rtl/freebsd dir. I think the kqueue.inc files should be in common BSD dir as 3 out of 4 major bsds (darwin being one) now support it. demo-kqueue1.pas is a simple process watching example.

Ales

P.S: the 2 syscall numbers should be added to freeBSD syscalls

Marco, should this not be added to packages ?

Michael.

if 3 out of the 4 major bsds support it shouldn't it be in a generic bsd unit?

peter green wrote

if 3 out of the 4 major bsds support it shouldn't it be in a generic bsd unit?

It should be split into include which belong to BSD and specific OS units which belong to specific OS dirs which use those includes.

Ales

i disagree, thats forcing unnessacery extra ifdefs into user code for no good reason.

imho if something is availible on muliple operating systems it should be availible in the same unit if at all possible.

It will force users into {$ifdefs} anyhow because older versions (especialy macosX where it's only since 10.3) won't work with it.

Ales

(4 out of 4 now it seems. There are some version requirements though, but they are relatively mild)

> P.S: the 2 syscall numbers should be added to freeBSD syscalls Marco, should this not be added to packages ?

It is all syscall stuff etc. (though I'll try to add FPC_USE_LIBC support before committing). It belongs in an "outer" rtl package, but there is no such thing.

Maybe we should finalize our plans for the tree structure and buildtools first, before starting to move stuff out of the RTL. (this being equivalent to the linux unit that IS in the rtl).

It will force users into {$ifdefs} anyhow because older versions (especialy macosX where it's only since 10.3) won't work with it.

If you drive this too far, you end up with a unit per function. Moreover, in time, the BSDs without it will get more rare.