Open danieljurek opened 1 year ago
@ellismg is this something which we can do and remove CGO deps?
@danieljurek Is this still needed? I introduced this change. We can remove this compile-time dependency, which is currently used to access OS information via objective-c syscalls, in favor of a runtime dependency that involves shelling out to an external tool as long as it's performant enough and is available on "old enough" macOS systems.
I believe @ellismg had mentioned it was non-noticeable, so it should be extremely feasible.
Removing our dependency on cgo would simplify cross compile scenarios by not requiring that we build on the target OS (easiest access to compiler toolchains and dependencies like headers, etc.). That is, you could build all binaries on a single platform, like Windows, without needing to run builds on separate pipeline jobs. The purpose of this is to simplify our tooling but the effects aren't really visible to the user. That is, low priority.
ALSO, if we're going to end up with later features which would require that we use cgo anywhere then any work done on this would be moot because we'll end up in the same place we are today. So we should only take this on if we're not going to end up requiring cgo again in the future.
On macOS
osutil
has a CGO dependency. This would simplify x-compile scenarios.