How to manage SWT .so files in my workspace

[jonahgraham]

In a follow up to #2539 (comment)

could explain it better, I believe you don't need to checkin any binaries in a PR, if native code is changed, Jenkins job will build everything needed and test with the updated binaries, and if merged, a job will be scheduled to push updated libraries to. I believe you should be able to see this in the git history.

Nope, cannot explain it better, that's exactly how it is. :) I can only add that also the GH actions rebuild the binaries for the platform they are running on. In general we try to avoid to have binaries contributed as they are very difficult to review.

Since I am not supposed to commit binaries as part of my PR (which makes a lot of sense) how do people manage numerous branches with binaries while developing? Is "git restore" the modified/uncommitted binaries + a rebuild of the binaries done each time a branch changes? Or do people have simpler/faster ways of doing it?

[laeubi]

@jonahgraham I think not many people are actually working with the native code so it might not be a problem for many.

Regarding git there are of course some options:

1. You can right click on a file in staging view then choose assume-unchanged
2. you can also stash stuff
3. As you mentioned just replace with head is also possible
4. Maybe one can do some fancy stuff wit git before/after hooks

In any case, I found it quite convenient to show the Git Staging view in my default java perspective what makes most these tasks quite easy to reach.

I would even say it is okay to commit the files to your branch, just restore the previous version before finally merge it to the repository (they will be overwritten anyways).

[akurtakov]

My approach is exactly this one - rebuild the binaries on every branch change aka threat them like any other build artifact.