Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/cgo: expand $GOPATH in -I and -L directives #20606

Closed
chewxy opened this issue Jun 8, 2017 · 3 comments

Comments

@chewxy
Copy link

commented Jun 8, 2017

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)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/chewxy/workspace/gorgoniaws/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build242930547=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2

What did you do want?

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.

@chewxy chewxy changed the title cgo: Expand $GOPATH variable cgo: Expand $GOPATH variable in preprocessing directives for -I and -L Jun 8, 2017

@bradfitz 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

@gopherbot gopherbot added this to the Proposal milestone Jun 8, 2017

@gopherbot gopherbot added the Proposal label Jun 8, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jun 12, 2017

Note that $GOPATH is not a single value; it is a list of paths. That complicates this proposal a bit.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2017

As does vendoring: if this package is vendored (along with its internal packages) then the -I option is not right anymore.

@rsc 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 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 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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 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.

@rsc rsc closed this Jul 17, 2017

@golang golang locked and limited conversation to collaborators Jul 17, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.