On Sat, Nov 27, 2021 at 11:01 AM David Karr <davidmichaelk...@gmail.com> wrote:
>
> I'm aware of the "build constraints" mechanism, which lets individual files
> be only compiled on specific oses or architectures.
>
> I am constructing an app that has a single cgo module, which is the "meat" of
> the application (longest module). In my poc, the cgo header specifies a lib
> path with "linux" in the path, to point to the linux libraries. I haven't
> constructed a Makefile for this yet, but this works well with vscode and
> simple testing.
>
> I now have to consider how to build this on Windows, although the deployment
> target for this will be Linux. I have to allow for testing of it on Windows,
> if possible. I thought perhaps that I could change the lib path in the cgo
> header to reference "${GOOS}" instead, but it doesn't seem to recognize that.
>
> It's not reasonable to use build constraints for this, because it seems like
> I would have to duplicate the entire module in order to vary the lib path.
> That would be absurd.
>
> What are reasonable strategies for this, including facilitating testing of it
> in vscode on both Linux and Windows?
If I'm reading this correctly, you can address this by using
GOOS/GOARCH build tags in your #cgo comments. See, for example,
https://go.dev/src/runtime/cgo/cgo.go?#L14. This is documented at
https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXFMUV12pBvOQhtZJOiiHzTje5gb2t6SZKzChB7yWG5_w%40mail.gmail.com.
