jextract fails to compile generated source

[Ty Young]

On 6/29/20 10:59 AM, Maurizio Cimadamore wrote:
>
> On 29/06/2020 16:36, Ty Young wrote:
>> Will there be the ability to dump layout information to a file added 
>> anytime soon? I understand plugins are a thing, but I really feel 
>> like there is a good use case where people just want to get layout 
>> information and nothing else and it should be supported by default. 
>
> https://gist.github.com/mcimadamore/5f002d8177e05780f068dd7874a5020b
>
> (this was shared few weeks ago).
>
> Yes, plugins _are_ a thing and I think it would be more constructive 
> to try and understand what the jextract _API_ can do in order for you 
> to generate the code the way you like it, rather than trying to 
> convince us that "the way you like it" should be "The Way (TM)".


Generating layout information is something jextract has to do for 
binding generation and it doesn't conflict with jextract's core 
functionality anymore than just dumping source code. I don't know where 
this is coming from. This is a mischaracterization of what was being asked.


For the record, I have done this already with my abstraction layer API 
and manually made bindings based on top of it. Making sure that all of 
those work from all the breaking changes(it's part of the incubating API 
game, I know) while trying to improve my own JavaFX application is 
already a bit much for someone who isn't actively paid to do it. If the 
expectation is that someone needs to do what I've done already or you 
need to make a plugin in order to add *incredibly minor* but useful 
functionality improvements(like this) to FMA, you're asking for a lot IMO.


As someone who is trying to keep up with the newest builds, just 
compiling the JDK can be difficult due to the CPU, memory, and bandwidth 
requirements. A few times now I've downloaded 300MB(IIRC) worth of 
source code only for it to not compile. Heck, I've even had to switch my 
previously Ant based projects to Maven because of the removal of Nashorn 
JavaScript engine in JDK 15, which Netbeans Ant modular projects used, 
just so I could continue to keep using new FMA builds.


I've sent suggestions, FYI, to skara-dev but the only suggestion they 
were willing to even comment on was *maybe* adding a source code passing 
badge based on internal Oracle build server statuses. I say *maybe* 
because it really didn't sound like there was any real desire to make it 
happen. I hope you(or anyone else at JDK) don't expect people to rent or 
build their own build servers just to actively use incubating features.


...but I digress, getting off-topic. Please don't shoot me.


>
> Separately, I personally find it hard to reconcile some of the 
> "requests" with things that have been said in the past. At some point 
> it was brought up the fact that jextract generated bindings were 
> platform-dependent (true) - and that this was a "Bad Thing". Now you 
> advocate that having a separation of declarations based on where the 
> headers are on your system is the way to go - I believe header 
> presence/absence/location is, perhaps the *least* stable thing you can 
> get in C-land?


Directory structure wasn't really the issue, but rather the detanglement 
of multiple headers from one file so that it can be reasoned where they 
are being generated from. Yes I realize the location changes but google 
exists. You can use information from one platform's structure to find 
the location on another.


If they were all thrown into a single package I could care less, 
personally. How someone wants to organize the bindings is up to personal 
preference - I've seen someone using Panama use /usr/include as a 
package structure. To each their own.


>
> Having all symbols in the same place helped in nearly all the samples 
> we tried out - of course this assumes that some filtering of the 
> output is applied (I covered that in a separate email). Otherwise you 
> will end up pulling up every knob of your system headers, which I 
> agree would be undesirable.


If you think 1000+ IDE code completion entries(ironically not even an 
exaggeration, it could happen) is desirable then I guess we'll have to 
agree to disagree I guess.


>
> Maurizio
>