Generated code differences accross OS

[Martin Pernollet]

Hi,

You are completely right. I started on MacOS with the OpenGL sample based on GLUT [1], and then continued on Windows and Ubuntu with FREEGLUT as suggested [2]. The API are almost similar, but the naming indeed changes (and freeglut has few additional utility not provided by GLUT for information). After installing freeglut on MacOS, I can see that the naming is consistent.

I'll try working with freeglut on Mac. If this works properly I can PR that change on the demo repo you made available on Github. This would avoid clarifying this difference here that I missed for a while :D [3].

I don't think this problem should arise again for anyone using the same headers so maybe overriding callback names is not important... unless a header file switches parameter names according to target platform - which would be really weird :) Beside this, if another use case justify renaming, the parameter naming you propose sounds perfect.

Thank you very much for taking time to clarify!

[1] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/compilesource.sh#L1
[2] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/compile_windows.ps1#L11
[3] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/README.md

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Le mardi 23 novembre 2021 à 13:00, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> a écrit :

> AFAIK, the only difference is that, depending on the glut library in
>
> use, the parameter name is different, and the resulting function pointer
>
> factory is also different (because we use the parameter name to infer a
>
> good factory name).
>
> I think that, as you point out, this naming strategy is a little
>
> unstable, as small differences (e.g. parameter names) end up with
>
> incompatible bindings.
>
> We do not have a page listing these kind of issues (we need to improve
>
> jextract documentation, we are aware of that). On top of my mind,
>
> differences can include:
>
> -   type mismatches (e.g. `long` means 32 bits on windows, and 64 bits on
>
>     linux)
> -   padding in structs might vary (largely because of the above)
> -   in some platforms some additional functions/struct members might be
>
>     defined
> -   macros vs. function differences - e.g. a function might be a real
>
>     shared library function on one platform/OS and just a macro in another
>
>     Assuming the library is written in a portable way (e.g. mainly avoids to
>
>     refer to types such as `long`), things should work relatively well - but
>
>     of course this is C and it is hard to generalize too much. In other
>
>     words, your mileage when reusing same extracted sources across
>
>     platforms/os is gonna vary, regardless of how smart jextract naming
>
>     choices are.
>
>     That said, if clients generate new bindings for each platforms, I think
>
>     jextract should try and depend only on public API names - otherwise it
>
>     becomes harder for clients of bindings (since a member can have name X
>
>     in one platform/OS and name Y in another).
>
>     So, assuming we fix this, what would be a good naming strategy for
>
>     callback factories? If we don't want to depend on the parameter name, an
>
>     alternative could be:
>
>     <funcName>$upcall
>
> or, if the same function has more than one:
>
> <funcName>$upcall$<pos>
>
> where `pos` is the callback parameter index in the function signature.
>
> Would that be satisfactory?
>
> Maurizio
>
> On 23/11/2021 11:17, Martin Pernollet wrote:
>
> > Hi,
> >
> > There is difference in code generated on Ubuntu and MacOS, e.g. :
> >
> > glutReshapeFunc$func on MacOS
> >
> > glutReshapeFunc$callback on Ubuntu
> >
> > Will this remain as is in future versions of JExtract? If this is intentional, what is the reason for this?
> >
> > This is a bit annoying for generating multiplatform bindings because this will requires writing (or generating) a wrapper on the generated code.
> >
> > I am interested if someone knows a page discussing all differences that may arise in code generated on different OS.
> >
> > Thanks,
> >
> > Martin