add freebsd support

[hoanga]

the following changeset allows go-llvm (as well as tinygo) to compile on freebsd (tested on freebsd 14.3). without the changes applied the following error occurs when trying to compile on freebsd

$ uname -a
FreeBSD quincy 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC amd64

$ go build ./...
# tinygo.org/x/go-llvm
./bitwriter.go:16:10: fatal error: 'llvm-c/BitWriter.h' file not found
   16 | #include "llvm-c/BitWriter.h"
      |          ^~~~~

[aykevl]

While I'm not opposed to this, I'm somewhat worried about having to maintain this - and likely breaking it. Is there a way to test these things in CI, even if it's just to see whether it compiles? (I guess that might be possible by installing a FreeBSD sysroot from somewhere?)

[b0ch3nski]

I've seen other projects using https://github.com/vmactions/freebsd-vm

[hoanga]

While I'm not opposed to this, I'm somewhat worried about having to maintain this - and likely breaking it. Is there a way to test these things in CI, even if it's just to see whether it compiles? (I guess that might be possible by installing a FreeBSD sysroot from somewhere?)

these are good points. i've setup an example ci workflow under a separate branch that tests using vm in freebsd approach (sample job run here). if that is acceptable as is, some options to go forward with are either:

• update pull request with updated branch
• fold changes into current branch with PR

i am not sure if adding a vm action might become unwieldy in everday use on this project (i imagine for some other much faster iterating projects, the extra build time might become a possible issue) but looks like it works. the current approach favors pushing all the logic into 1 vm as i am not sure if trying to spawn a matrix of jobs for vms is a great idea for github actions. i understand some other ci flavors like cirrus ci do offer freebsd support as well if that is an option that might be considered (at the cost of extra workflow definitions)

[aykevl]

I have refactored the config files here: #71
With this change, FreeBSD support would just mean a few extra lines in these config files and they'd be easy to keep up to date. It's been like this in TinyGo and hasn't been an issue so far. See: https://github.com/tinygo-org/tinygo/blob/release/cgo/libclang_config_llvm20.go

@hoanga do you think that's a good idea? In that case, I can merge #71 and this PR could be remade on top of that. I can't guarantee FreeBSD will continue to work, but it's harder to accidentally mess up than if FreeBSD support still exists in separate files.

[hoanga]

I have refactored the config files here: #71 With this change, FreeBSD support would just mean a few extra lines in these config files and they'd be easy to keep up to date. It's been like this in TinyGo and hasn't been an issue so far. See: https://github.com/tinygo-org/tinygo/blob/release/cgo/libclang_config_llvm20.go

@hoanga do you think that's a good idea? In that case, I can merge #71 and this PR could be remade on top of that. I can't guarantee FreeBSD will continue to work, but it's harder to accidentally mess up than if FreeBSD support still exists in separate files.

the refactoring looks a little cleaner from what i can tell. i am used to and have seen the per-os file pattern separation in go in other projects. however, if tinygo is using an alternate strategy that is working for the project, having less overall multiple conventions to decrease maintenance burden makes sense to me. the changes look okay to me and i can rebase the changes that would make sense afterwards.

my ulterior goal is to get the tinygo port updated in freebsd-ports so having less patches to add onto the ports system would be preferred.

[hoanga]

i updated the freebsd-support-ci branch to incorporate changes from #71.

sample job results are here. looks okay for llvm19 and llvm20. llvm21 package does not look like it is available in package repos referenced in vm.

[b0ch3nski]

I think you could utilize the 'matrix' feature like it's done for other OS for a cleaner CI setup

strategy:
  matrix:
    llvm: [19, 20]

[hoanga]

I think you could utilize the 'matrix' feature like it's done for other OS for a cleaner CI setup

strategy:
  matrix:
    llvm: [19, 20]

i am skeptical that enabling vm actions within a matrix is a good idea (see earlier comment) even if it 'cleans up' the yaml declarations.

also see this

[b0ch3nski]

also see this

@hoanga I think that this pipeline has failed because of the mistake in yaml here:

pkg install -y ${{ matrix.llvm }}

This templating would just inject a number, while you would need something like llvm${{ matrix.llvm }} (based on your commit: hoanga@ba49540)

[hoanga]

also see this

@hoanga I think that this pipeline has failed because of the mistake in yaml here:

yes, you are correct. i made another attempt attempting the matrix with better results (here). the freebsd-support-ci should have the latest changes.

much appreciated on the gentle pointer to fixing an (obvious) pebkac entry error.

[aykevl]

I've merged #71.
With this change, the extra maintenance overhead of FreeBSD is much much smaller, I'd be fine with just adding lines like the following to the config files:

// #cgo freebsd CPPFLAGS: -I/usr/local/llvm20/include -I/usr/local/llvm20/include/llvm-c -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
// #cgo freebsd CXXFLAGS: -std=c++17
// #cgo freebsd LDFLAGS: -L/usr/local/llvm20/lib -lLLVM

They'd be easy to update with new LLVM versions. I would still consider FreeBSD to not be fully supported as long as we aren't able to run TinyGo tests on FreeBSD in CI, but if anything breaks that should be easy to fix.

my ulterior goal is to get the tinygo port updated in freebsd-ports so having less patches to add onto the ports system would be preferred.

Cool! I'm happy to have small patches in TinyGo if they make FreeBSD support easier. For example, we also have a few small changes purely for NixOS so they don't need to patch as much on their side.

[aykevl]

(just making it clear this PR needs some updates to be ready to merge, see comment above)

[hoanga]

(just making it clear this PR needs some updates to be ready to merge, see comment above)

i've rebased the changes for freebsd on current master. i originally also tried to put in the ci definitions for freebsd but i have removed the freebsd ci for now as it seems that the ci runs can be fickle with added vm actions.

i can add it back in if the finicky behavior is acceptable or i can create a separate PR if that is preferred.

[aykevl]

Can you indent the lines like this, consistent with the rest of the file?

Suggested change

	// #cgo freebsd CPPFLAGS: -I/usr/local/llvm19/include -I/usr/local/llvm19/include/llvm-c -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
	// #cgo freebsd CXXFLAGS: -std=c++17
	// #cgo freebsd LDFLAGS: -L/usr/local/llvm19/lib -lLLVM
	// #cgo linux CPPFLAGS: -I/usr/include/llvm-19 -I/usr/include/llvm-c-19 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
	// #cgo freebsd CPPFLAGS: -I/usr/local/llvm19/include -I/usr/local/llvm19/include/llvm-c -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
	// #cgo freebsd CXXFLAGS: -std=c++17
	// #cgo freebsd LDFLAGS: -L/usr/local/llvm19/lib -lLLVM
	// #cgo linux CPPFLAGS: -I/usr/include/llvm-19 -I/usr/include/llvm-c-19 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

(Same goes for the other two files).

[hoanga]

Sure, updated (sorry for not catching that earlier).

[aykevl]

Thank you! This will get pulled the next time we update go-llvm in TinyGo.
You can make a PR if you want to have this updated sooner.