Bazel build of purego failing

[eliottness]

Bazel does not use the go usual build process for an increase in building speed. For this, they use their usual sandbox which makes the current working directory a random temporary directory and not the current package. This makes cross-package #include unable to work since the included file is not at the right place at build time. Here is the error:

external/com_github_ebitengine_purego/internal/fakecgo/asm_arm64.s:7: 
#include: open /var/folders/fn/j3_08pb94p9_hyz4myff84br0000gq/T/abi/abi_arm64.h: no such file or directory
compilepkg: error running subcommand external/go_sdk/pkg/tool/darwin_arm64/asm: exit status 1

The files where it fails are the following:

• internal/fakecgo/asm_amd64.h
• internal/fakecgo/asm_arm64.h
• sys_amd64.h
• sys_arm64.h

Purego is especially useful in Bazel environments because CGO is disabled by default. I checked on bazel side and this behaviour seems unavoidable. Do we know if cross-package usage of #include is really something that is officially supported (in which case bazel is at fault) and not a happy coincidence ? It is only a matter of copying the files in purego/internal/abi to purego/internal/fakecgo and purego/, in which case I can do the PR, or am I missing something ?

[hajimehoshi]

Which Go version are you using?

[eliottness]

Which Go version are you using?

@hajimehoshi 1.20.5. Is this related ?

[hajimehoshi]

There is a known issue for Go 1.21 #140 so the version is an important information.

[TotallyGamerJet]

The assembler is poorly documented so if it's "officially" supported is mostly implementation defined. It's probably best to create an issue with Bazel to see if they'll fix it. Otherwise, I'm not sure how I feel about the copying since that would duplicate the abi headers.

[eliottness]

I finally had the time to push this, we will see how they respond 👍

[eliottness]

I looked into the project since the issues does not seems to be taken care of. And it seems that I will be really hard to make this work because each package is compiled in a separate sandbox. So this cross package include goes against the whole bazel sandboxing system.

@TotallyGamerJet I understand your concerns about copying the files and if I had any other working option I would present it to you but purego is a tool we intended to use on bazel in the first place, so it's a must on our side. Is there room for discussion ?

[eliottness]

If the issue is about duplicating some code that was already copied from elsewhere, then we could build a small markdown table somewhere to reference all the files copied and where they come from. Just like you did in the README but more elaborate

[TotallyGamerJet]

My concern was that if upstream Go changes the files then we have to remember to update it in all locations. However, I don't know any other solution and it's important to have bazel working

[eliottness]

We could create a job scheduled every X than would git clone and diff the files. Just like we could find the dev build stream and try to run purego regularly on it.

[TotallyGamerJet]

That seems a little over-engineered for 4 files that don't change every release. I say we just copy them for now. You can make that PR if you want or wait until later for me to do it.

[eliottness]

That seems a little over-engineered for 4 files that don't change every release. I say we just copy them for now. You can make that PR if you want or wait until later for me to do it.

I guess you are right. I have done the PR 👍