Add path independence

[minborg]

This small PR incorporated feedback from the original PR: #66 made after it was integrated.

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed (no review required)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jextract.git pull/68/head:pull/68
$ git checkout pull/68

Update a local copy of the PR:
$ git checkout pull/68
$ git pull https://git.openjdk.org/jextract.git pull/68/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 68

View PR using the GUI difftool:
$ git pr show -t 68

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jextract/pull/68.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back minborg! A progress list of the required criteria for merging this PR into panama will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@minborg This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

Add path independence

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 11 new commits pushed to the panama branch:

• ff8ce04: 7903485: Windows.h fails to extract on jextract/panama
• c3deba2: 7903481: Jextract doesn't enforce group layout alignment correctly in some cases
• 3f41267: 7903475: Jextract should use new byte-based layout methods
• 9feb042: 7903463: jextract generates empty padding layouts
• f3c7c85: 7903449: Jextract generates structs that cannot be compiled
• 750c415: 7903314: Jextract doesn't honor pack pragmas
• dfcca5b: Simplify code to use withoutName
• c1fce3b: Update jextract to reflect latest API tweaks
• dfafbbe: 7903437: Improve translation strategy for function pointers
• 8f41279: fixed samples for API change MemorySegment.slice -> asSlice and to re-extract libjimage binding
• ... and 1 more: https://git.openjdk.org/jextract/compare/4863194ddd5cdfda0b0160cf51cde30fa022187b...panama

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@sundararajana) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[mlbridge]

Webrevs

• 01: Full (34985c6a)
• 00: Full (7c8d1664)

[sundararajana]

I guess we need similar change for many other samples. One flip side of the approach in this PR that we lose the specific version to use. C APIs need not be backward compatible (many are not!). Sample may work on a specific version of C library and not on the latest (or older) brew installed version.

[minborg]

Perhaps we could mention a specific version in the README file (e.g. the example here is verified for foo version x.y.z) and that appropriate changes might have to be made if another version is used.

[bondolo]

I guess we need similar change for many other samples. One flip side of the approach in this PR that we lose the specific version to use. C APIs need not be backward compatible (many are not!). Sample may work on a specific version of C library and not on the latest (or older) brew installed version.

As long as the library remains compatible the sample should continue to work. It seemed wrong to install a non-specific version using homebrew (or apt or yum) and then expect that specific version had been installed.

I agree with the suggestion that the readme should document which version of the library was used.

[bondolo]

LGTM!

It is tempting to get fancy and implement everything needed to simultaneously support Linux and MacOS but the result would obscure the clarity of the sample so I agree to keep it simple.

(I am an OpenJDK Panama committer but have been inactive for 8+ years on the project so defer to more active contributors for approval).

[sundararajana]

Note: "As long as the library remains compatible.." That is not true for all samples. For eg. libffmpeg has broken compatibility. Only specific older version works. May be the PR title should "Add path independence for libzstd sample".

[openjdk]

@minborg this pull request can not be integrated into panama due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout libstd2
git fetch https://git.openjdk.org/jextract panama
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge panama"
git push

[bridgekeeper]

@minborg This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@minborg This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.