Best practice for using h2pas on a "clever" kernel interface binding

[PascalDragon]

https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

With just a quick look I can see that it uses some functionality (both features and classes) that FPC does not yet support so that would have to be ported...

[MarkMLl]

https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

With just a quick look I can see that it uses some functionality (both features and classes) that FPC does not yet support so that would have to be ported...

Much my suspicion. That's not something I can realistically do: I'm quite simply not sufficiently up-to-speed on what Delphi's doing these days, and I've got my hands full with- among other things- trying to sort out details of GPIO naming convention (the gpiod API fails to report the base of a group of lines).

MarkMLl

[MarkMLl]

I've got a substantial number of entry points named like

Code: Pascal  [Select][+][-]

1.   function gpiod_is_gpiochip_device(path:Pchar):boolean; CDECL__ GPIODLIB__
2.   function gpiod_chip_open(path:Pchar):pgpiod_chip; CDECL__ GPIODLIB__
3.   procedure gpiod_chip_close(chip:Pgpiod_chip); CDECL__ GPIODLIB__
4.   function gpiod_chip_name(chip:Pgpiod_chip):Pchar; CDECL__ GPIODLIB__
5.  

That's from an include file which is incorporated into automatically-generated units for static and dynamic linkage.

The objective is that these will always be accessed using either a unit name or an object reference, i.e. like

Code: Pascal  [Select][+][-]

1.   chipHandle := Gpiod.gpiod_chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
2.   gpios := Gpiod.gpiod_chip_num_lines(chipHandle);
3.  

In principle I could trim the leading gpiod_ in each function name as redundant, but in order to avoid ambiguity is there any way that I could mark the static unit as always requiring fully-qualified references, i.e. so that

Code: Pascal  [Select][+][-]

1.   chipHandle := chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
2.   gpios := chip_num_lines(chipHandle);
3.  

was not accepted by the compiler?

MarkMLl

[PascalDragon]

In principle I could trim the leading gpiod_ in each function name as redundant, but in order to avoid ambiguity is there any way that I could mark the static unit as always requiring fully-qualified references, i.e. so that

Code: Pascal  [Select][+][-]

1.   chipHandle := chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
2.   gpios := chip_num_lines(chipHandle);
3.  

was not accepted by the compiler?

No, you can't.

[avra]

https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

It is Delphi application and I did not suggest that you need to compile it under Lazarus. On the right side of the site you can see Releases link. Press it and download executable. Nothing more, nothing less. I use it mostly for quick translations because of it's live feature which translates on idle, and as an alternative translation to choose from.

[MarkMLl]

I'm taking another look at the varargs aspect of this, and would appreciate a reality check.

The documentation of class helpers says that a class helper can't define a (new) field or as a consequence a property referring to a field... Does this apply to fields defined in the base class, or it it only stating the obvious that since fields can't be defined in a helper a property referring to a newly-defined field can't be created?

MarkMLl