bazel: publish a new version to bazel registry

[jimmyl02]

Hi there, I'm creating an issue to see if there is a way we can get the latest version published to the bazel registry. It seems like the latest version is 1.3.8 which is a bit outdated.

It seems like importing circl via bzlmod this way is a good way to resolve the amd64 compilation issues (due to missing header) from issues like this: bazel-contrib/rules_go#3799 (comment) and bazel-contrib/bazel-gazelle#1421

This would be a big help to not have to do a hacky patch like https://github.com/satreix/everest/blob/7026e38065d2dece92a1bced59083f85928bf638/third_party/go/deps.bzl#L103-L104

Longer term, I wonder if it's possible to help resolve this issue in general via a contribution to circl? Unfortunately I'm not an expert on bazel / gazelle / circl so I'm not sure of the best solution here. Thanks for the help and any insights! This would definitely reduce a lot of the friction when using this library via bazel

[armfazh]

Firstly, the main issue is that bazel-galleze discards *.h files from Go packages, because it detects them as C header files.

CIRCL is a Go(+assembler) only project. However, CIRCL uses .h files for storing assembly macros (Plan9). These header files have nothing to do with CGO.

Looking at the issues (and workarounds) to make CIRCL working with bazel, the main issue above must be solved by bazel-galleze, so it doesn't exclude header files. However, to be fair, it could be difficult in general to distinguish between C-headers and assembler-headers.

In CIRCL's court, we could rename assembly-header files, e.g., fp_amd64.h -> fpHeader_amd64.s, the Go compiler still works. However, I would like to gather feedback from bazel users whether this change can make compilation easier, and finally solve the problem.
See #540

[albertocavalcante]

Firstly, the main issue is that bazel-galleze discards *.h files from Go packages, because it detects them as C header files.

CIRCL is a Go(+assembler) only project. However, CIRCL uses .h files for storing assembly macros (Plan9). These header files have nothing to do with CGO.

Looking at the issues (and workarounds) to make CIRCL working with bazel, the main issue above must be solved by bazel-galleze, so it doesn't exclude header files. However, to be fair, it could be difficult in general to distinguish between C-headers and assembler-headers.

In CIRCL's court, we could rename assembly-header files, e.g., fp_amd64.h -> fpHeader_amd64.s, the Go compiler still works. However, I would like to gather feedback from bazel users whether this change can make compilation easier, and finally solve the problem. See #540

@fmeum can you give your opinion on this? Thanks!

[Lekensteyn]

The bazel go_rules go_library documentation for srcs says:

Only .go, .s, and .syso files are permitted, unless the cgo attribute is set, in which case, .c .cc .cpp .cxx .h .hh .hpp .hxx .inc .m .mm files are also permitted.

The Go assembler documentation does mention a couple of .h files such as textflag.h, funcdata.h, and go_tls.h from the standard library, and go_asm.h which is autogenerated and already special-cased since bazel-contrib/rules_go#1262. It does not explicitly suggest that users can include arbitrary files with macro definitions although there are a couple of examples if you search the standard Go library for example:

$ git grep -nPe '#include "(?!cgo|(\.\./)*(runtime/)?(textflag|go_asm|go_tls|funcdata)\.h")' ':!**cgo**'
...
src/internal/bytealg/equal_amd64.s:6:#include "asm_amd64.h"
src/reflect/asm_ppc64x.s:9:#include "asm_ppc64x.h"
...

While bazel-gazelle could be fixed to recognize these included macro files (bazel-contrib/bazel-gazelle#1393), that might not happen (soon). I think that a workaround on our side is reasonable.