Access to OS specific constants

[Maurizio Cimadamore]

Hi,
the API does not provide a way to probe the OS/arch.

Our linker implementation does it with this blob of code:

https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/java.base/share/classes/jdk/internal/foreign/CABI.java#L39

There is nothing magic in here, just some checks on JDK properties, so I 
believe this code could be more or less copied into your project.

Of course it would be nice one day to provide an official query mechanism.

Maurizio

On 03/06/2022 14:53, Guillaume Nodet wrote:
> Yes, those constants are defined as macros in headers.
> The "--include-macro" is for jextract, right ? But this will generate
> static code for the platform I'm running jextract on IIUC.  My problem is
> that those constants do not have the same values, depending on the OS, so I
> do need something dynamic.
>
> Le ven. 3 juin 2022 à 15:30, Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com> a écrit :
>
>> Are those constants #define'd as macros in headers? If so, you can extract
>> (even selectively filter by --include-macro option). If those are from
>> platform specific headers, you can still extract multiple headers and use a
>> import static *
>>
>> -Sundar
>> ------------------------------
>> *From:* panama-dev <panama-dev-retn at openjdk.java.net> on behalf of
>> Guillaume Nodet <gnodet at apache.org>
>> *Sent:* 03 June 2022 18:17
>> *To:* panama-dev at openjdk.java.net <panama-dev at openjdk.java.net>
>> *Subject:* Access to OS specific constants
>>
>> I'm experimenting JEP 424 to support Jansi (
>> https://github.com/fusesource/jansi), JLine (
>> https://github.com/jline/jline3)
>> and mvnd (https://github.com/apache/maven-mvnd).
>>
>> I've been able to replace a few native calls with the experimental API
>> [1].  However, there's one thing I'd be missing in order to completely get
>> rid of the native code : the java code needs to call the ioctl function
>> [2], but that one takes an integer which value is defined in C headers.  In
>> my case, this is the TIOCGWINSZ constant, which is defined in my library
>> class [3] and initialized in the native code [4]. When the libraries are
>> using JNA, I need to define specific constants for each system, see [5],
>> [6], [7].  But this kinda defeats the purpose of portability.
>>
>> Any idea how to work around this problem ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>> [1] https://github.com/fusesource/jansi/tree/jep-424
>> [2]
>>
>> https://github.com/fusesource/jansi/blob/jep-424/src/main/java/org/fusesource/jansi/AnsiConsoleHelper.java#L82
>> [3]
>>
>> https://github.com/fusesource/jansi/blob/jep-424/src/main/java/org/fusesource/jansi/internal/CLibrary.java#L63
>> [4]
>>
>> https://github.com/fusesource/jansi/blob/jep-424/src/main/native/jansi.c#L58
>> [5]
>>
>> https://github.com/jline/jline3/blob/master/terminal-jna/src/main/java/org/jline/terminal/impl/jna/freebsd/CLibrary.java#L250
>> [6]
>>
>> https://github.com/jline/jline3/blob/master/terminal-jna/src/main/java/org/jline/terminal/impl/jna/linux/CLibrary.java#L267
>> [7]
>>
>> https://github.com/jline/jline3/blob/master/terminal-jna/src/main/java/org/jline/terminal/impl/jna/solaris/CLibrary.java#L267
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>