You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
package main
// #cgo CFLAGS: -g -O3 -std=c99
// #cgo CFLAGS: -I${GOPATH}/github.com/chewxy/path/to/internal/sharedheaders
// #include "fromshared.h"
// #include "fromlocaldir.h"
import "C"
func main() {
var a C.int
C.sharedfuckall(a)
C.localfuckall(a)
}
What did you expect to see?
Compilation to complete.
What did you see instead?
Compilation failed.
Workarounds
Instead the ugly solution is really ugly: you'd have to use the full absolute path:
#cgo CFLAGS: -I/full/abs/path/to/headers
Another solution would be copy the .h files into each individual directory. This makes building libraries a bit messy and reliant on abs paths (for context, I'm working on improvements on the CUDA library), and would most likely require things like makefiles, which makes a library unappealing to use/install.
Currently cgo accepts ${SRCDIR} to handle statically compiled libs to be included in a directory.
So you can see why a solution which expands ${GOPATH} the same way ${SRCDIR} would be nice to have, and I suspect, fairly trivial to add. The checks for internal packages may be a bit tricky.
References/Related Issues
Issue #19745 : @bradfitz and @rsc said that the goal of cmd/go is not to be a C build tool. To which I agree. I propose only limiting this to internal packages. This does away with the problem of implicit dependency issues (the logic of it goes: all the dependencies go into the internal package anyway as a "final destination")
Thoughts appreciated.
The text was updated successfully, but these errors were encountered:
chewxy
changed the title
cgo: Expand $GOPATH variable
cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
Jun 8, 2017
bradfitz
changed the title
cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
proposal: cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
Jun 8, 2017
As does vendoring: if this package is vendored (along with its internal packages) then the -I option is not right anymore.
rsc
changed the title
proposal: cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
proposal: cmd/cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
Jun 13, 2017
rsc
changed the title
proposal: cmd/cgo: Expand $GOPATH variable in preprocessing directives for -I and -L
proposal: cmd/cgo: expand $GOPATH variable in -I and -L directives
Jun 13, 2017
rsc
changed the title
proposal: cmd/cgo: expand $GOPATH variable in -I and -L directives
proposal: cmd/cgo: expand $GOPATH in -I and -L directives
Jun 13, 2017
cgo always puts a -I <path to package dir> onto the command line, so if you have headers in some directory at a fixed location relative to the package dir, you should be able to #include with a relative path. For example if your code is in github.com/chewxy/mypkg and you want the headers in github.com/chewxy/path/to/internal/sharedheaders, then #include "../path/to/internal/sharedheaders/header.h" should work. That seems like the best solution here, since it avoids assumptions about $GOPATH or vendoring or anything else.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8.3 linux/amd64
What operating system and processor architecture are you using (
go env
)?What did you
dowant?What did you expect to see?
Compilation to complete.
What did you see instead?
Compilation failed.
Workarounds
Instead the ugly solution is really ugly: you'd have to use the full absolute path:
Another solution would be copy the
.h
files into each individual directory. This makes building libraries a bit messy and reliant on abs paths (for context, I'm working on improvements on the CUDA library), and would most likely require things like makefiles, which makes a library unappealing to use/install.Currently cgo accepts
${SRCDIR}
to handle statically compiled libs to be included in a directory.So you can see why a solution which expands
${GOPATH}
the same way${SRCDIR}
would be nice to have, and I suspect, fairly trivial to add. The checks for internal packages may be a bit tricky.References/Related Issues
Issue #19745 : @bradfitz and @rsc said that the goal of cmd/go is not to be a C build tool. To which I agree. I propose only limiting this to
internal
packages. This does away with the problem of implicit dependency issues (the logic of it goes: all the dependencies go into theinternal
package anyway as a "final destination")Thoughts appreciated.
The text was updated successfully, but these errors were encountered: