start to using CGO on cpu/cpu_darwin

[shirou]

I know there are many people who want to get CPUTimes on darwin using CGO. I had rejected because of easy cross-compiling. I had wrote using helper process. But yes, this is bad approach. And I think there is no way to get host_processer_info from pure Go because this is belongs to Mach part of darwin.

So, now, I have changed my mind.

Since 47f6760cf36f1ee42b4adf32a201835eb5c2ae57, cpu_darwin uses CGO. Current code is borrowed from influxdb/telegraf. Thank you using gopsutil!)

If someone want to remove CGO dependency, please write comments for this issue. I will remove quickly.

I always grateful to such a many people using, discussing, and contributing gopsutil.

reference

• 31

• 57

[vrecan]

:+1:

[dadgar]

I would prefer this removed because as you said it makes cross compiling difficult. Using tools like gox is much harder with this now.

[shirou]

@dadgar thank you for the :-1:

I have an idea about to use a build tag to easy cross compiling. It means, make two kind of files about darwin.

• cpu_darwin_cross.go
  • // +build darwin cross
  • no CGO, just return NotImplementedError on CPUTimes()
• cpu_darwin.go
  • // +build darwin !cross
  • use CGO

If you want to cross compile (and can accept could not get CPUTimes on darwin), type go build -tags=cross. Then, cpu_darwin_cross.go is used for cross-compile.

How do you feel it? Thank you.

[dadgar]

Yeah I like your thinking. You could probably use the cgo tag right? `

[shirou]

Ah! cgo build tag is the right way. Totaly agree. I made a PR #89. could you check it out?

[Comdex]

Let user to choose use cgo or not when compile the code is a good idea

[shirou]

@Comdex You can change CGO_ENABLE environment variable.

[jesse-c]

Quick tip for anyone wondering, it's CGO_ENABLED. See: https://golang.org/cmd/cgo/.