Wayland McWayface tutorial project done, feedback on jextract

[Mark Hammons]

I'm not so sure that's an issue with jextract. On the command line, -C 
"-DWLR_USE_UNSTABLE" works, but when using the ProcessBuilder apis 
(either scala's or ToolProvider's), a string "\"-DWLR_USE_UNSTABLE\"" 
doesn't work and isn't recognized as a valid option. The big issue with 
jextract and the toolprovider is that I got no error output indicating 
the problem (which I promptly got when using scala's ProcessBuilder api).

~Mark

On 04/03/2019 22:38, Maurizio Cimadamore wrote:
> So, to make sure I understand the issue
>
> the command line looked like:
>
> -C"-DWLR_USE_UNSTABLE"
>
> and nothing was passed onto clang?
>
> If so, I think we should investigate, as it sounds like an option 
> parsing issue.
>
> Thanks
> Maurizio
>
> On 04/03/2019 20:33, Mark Hammons wrote:
>> Thanks, I'll look forward to it! On a side note, I've released a new 
>> version of my project that finally has the sbt jextract integration 
>> working properly. It turns out that the -C parameter didn't like the 
>> quotes I was putting around "-DWLR_USE_UNSTABLE" and not recognizing 
>> the option, so that option wasn't being passed to clang, and clang 
>> won't work with this version of wlroots unless that option is passed. 
>> I found this out when I reimplemented the functionality using scala's 
>> process api instead of the toolprovider api. Still not sure why the 
>> tool provider wasn't printing that error message but oh well.
>>
>> On 3/4/19 12:01 PM, Maurizio Cimadamore wrote:
>>>
>>> On 04/03/2019 10:26, Mark Hammons wrote:
>>>> One last question. As I mention in my readme, I've written a 
>>>> binding for stdlib's setenv function in scala as opposed to getting 
>>>> jextract to generate it for me (because of the concerns I voiced 
>>>> before). It's in the package usr.include in the scala source code. 
>>>> Is it necessary that I define the header file at all in these 
>>>> bindings? I'd imagine I'd normally have to include the library to 
>>>> link against (but it's not necessary since it's part of libc), but 
>>>> if I can leave out the header annotation it's easier to make 
>>>> semi-platform independent bindings like what I could do with jnr. 
>>>
>>> Two answers here. In the long run, it is very likely that, as Panama 
>>> gets mature, we'll start seeing 'official' stdlib and/or posix Java 
>>> libraries (maybe in the JDK, maybe not).
>>>
>>> Another answer - it will eventually be possible to go 'lower level' 
>>> and obtain method handles to model native function calls 
>>> programmatically, w/o necessarily going through an annotated 
>>> interface, using just the Layout API. I will share more on that 
>>> story at a later point, but stay tuned.
>>>
>>> Maurizio
>>>
>>>
>>>