Code changes required after JDK-8291473

[Maurizio Cimadamore]

Should be fixed now. Look at the panama branch here:

https://github.com/openjdk/jextract/tree/panama

Maurizio

On 09/08/2022 09:29, Filip Krakowski wrote:
> Hi,
>
> this sounds great! Once the changes get pushed I will include 
> jextract's "panama" branch into our CI pipeline, so that we always 
> have a version that is in sync with the latest "foreign-memaccess+abi" 
> branch.
>
> Thanks for the quick response! Looking forward to trying out it out :)
>
> Best regards,
> Filip
>
> On 08.08.22 19:44, Maurizio Cimadamore wrote:
>> After some internal discussion, we are going to do the following:
>>
>> * create a "panama" branch, which contains the changes needed to run 
>> jextract with the API contained in the Panama repo
>> * have (as now) a set of versioned branches, for jdk18 and jdk19
>> * when 20 becomes GA, we will create a new jdk20 branch, copy the 
>> contents of the "panama" branch into it and make it the default branch
>> * we will _not_ provide binary snapshots for the "panama" branch, as 
>> that's a "bleeding edge" sort of scenario (where you have to build 
>> the panama repo manually to go with it as well)
>>
>> Cheers
>> Maurizio
>>
>>
>> On 05/08/2022 12:31, Maurizio Cimadamore wrote:
>>> Hi Filip,
>>> due to various complex reasons, it is currently not possible for us 
>>> to release binary snapshots using GitHub actions. All the binaries 
>>> we publish come from an internal CI pipeline, which builds and test 
>>> using predefined, well-known configurations, so that we can ensure 
>>> repeatable results. While this is not set in stone, and OpenJDK is 
>>> relatively new to GitHub workflows, I think that, for the time 
>>> being, we have to work with what we've got.
>>>
>>> That said, nothing prevents us from creating several internal 
>>> pipelines, one per jextract version, and add a new one every 6 
>>> months or so, perhaps with some policy to "garbage collect" old 
>>> pipelines (e.g. maybe providing binaries up to JDK N-3 would be a 
>>> good starting point?) - although I'd have to check with the infra 
>>> team and see what solution they'd be most comfortable with.
>>>
>>> P.S. While it would be possible, in principle, for 3rd parties to 
>>> build snapshots of jextract, I find that solution less ideal. 
>>> Plugins such as yours need a stable link to work with. A 3rd party 
>>> build might be a great place to get started (or where to get more 
>>> frequent jextract binary updates, for example), but doesn't provide 
>>> (by design) that kind of long-term commitment that some of the tools 
>>> in the ecosystem would require, at least IMHO.
>>>
>>> Thanks
>>> Maurizio
>>>
>>> On 05/08/2022 11:23, Filip Krakowski wrote:
>>>> Hi,
>>>>
>>>> is it a question of maintainability (diverging branches in case of 
>>>> patches, etc.), which would stand in the way of this, or a question 
>>>> of the infrastructure that would be required? In the latter case, I 
>>>> could try to set something up to accomplish the job of 
>>>> automatically creating releases from each pushed tag matching a 
>>>> version number.
>>>>
>>>> Since the project is hosted on GitHub, I could implement a GitHub 
>>>> Action, which would be triggered on each pushed tag. This Action 
>>>> would then compile the code for different platforms (Linux, macOS, 
>>>> Windows - GitHub provides images for each), create a release inside 
>>>> the repository and attach the created binaries to it. The 
>>>> repository already contains a GitHub Action for building and 
>>>> testing jextract, which I could use as a starting point.
>>>>
>>>> Best regards,
>>>> Filip
>>>>
>>>> On 04.08.22 21:14, Maurizio Cimadamore wrote:
>>>>>
>>>>> On 04/08/2022 20:08, Filip Krakowski wrote:
>>>>>> Each branch would therefore only produce binaries when it 
>>>>>> receives a new tag. Could this work? 
>>>>>
>>>>> I'd have to check - my feeling is that, no that would not be 
>>>>> possible.
>>>>>
>>>>> Another issue is that we'd need to keep updating the main github 
>>>>> branch every few months (not a big issue).
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>
>