cgo generates some files in PWD, others in source directory.

[gopherbot]

by [email protected]:

What steps will reproduce the problem?
1. cgo some/other/directory/thing.go


What is the expected output? What do you see instead?
_cgo_defun.c, _cgo_gotypes.go and the debug _cgo_.o file end up in PWD. 
Rest of the generated files end up in some/other/directory.

Noticed this doing an out of source build.

What is your $GOOS?  $GOARCH?
linux amd64

Which revision are you using?  (hg identify)
fbb9055eedba+ tip


Please provide any additional information below.
Attached a local patch to make all files get generated in the source directory.

Attachments:

1. cgo.patch (3305 bytes)

[rsc]

Comment 1:

Labels changed: added cgo.

Owner changed to [email protected].

Status changed to Accepted.

[gopherbot]

Comment 2 by [email protected]:

Noticed today that I was a little hasty with that patch.  It will crash if you don't
give cgo anything it recognizes as a go file.
And I've also noticed that just my original measure isn't sufficient when trying to
integrate with a out-of-source build build system where the easiest path is to keep
generated files in a separate tree than the original source. So I'm attaching a
second path that makes is so you can also specify the destination directory for the
generated files with an environment variable.  ie:
    CGOUTDIR=/some/destination cgo -I.. /some/source/dir/something.go
I used an environment variable because it was easy, and did't require making a major
change in how cgo handles the command line.  I don't care what the mechanism is as
long as there's a way to do it.

Attachments:

1. cgo2.patch (4407 bytes)

[dhobsd]

Comment 3:

Using cgo is relatively tied into using Make.pkg at the moment, but it looks like
this does affect us with the case of
CGOFILES=subdir/lib1.go subdir/lib2.go
I guess it isn't enough to have CGO put the output into subdir, since you could also
have:
CGOFILES=subdir1/lib.go subdir2/lib.go
(which I think is a notoriously bad idea, but perhaps valid for some reason).
Introducing new command line options into cgo is indeed a huge pain in the butt.
Having a way to specify where the autogenerated files could be desirable, but does
make the Make.pkg rules more complicated: running make clean assumes these files are
in CWD as well, for instance.
There are also a few rather minor issues in this patch. I'm happy to run with this
patch; I'm also happy to review it and offer suggestions if you'd like to work on
this functionality via codereview. See http://golang.org/doc/contribute.html if
you're interested -- otherwise let me know and I'll hammer your patch into something
`fuller'.

[gopherbot]

Comment 4 by pat.kelley:

I can work around this intended behavior, feel free to close this out.

[gopherbot]

Comment 5 by tnagy1024:

#3: putting the output files in various locations is uncommon.
Yet, using a build directory is the main problem. At the moment the files must be moved
manually and removed too in case of a failure:
.
├── build
│   ├── _cgo_defun.c
│   ├── _cgo_gotypes.go
│   ├── _cgo_.o
├── gmp.cgo1.go
├── gmp.cgo2.c
├── gmp.go

[rsc]

Comment 6:

all the output should go to current directory.

Status changed to Started.

[gopherbot]

Comment 7 by tnagy1024:

#6: yes, this would be better

[rsc]

Comment 8:

This issue was closed by revision 0432f28.

Status changed to Fixed.