cmd/go: Support C/C++ compiler flags when using SWIG through the build tool

[ane]

In tip, there's support for using SWIG through the build tool. This works actually
really well now, but one problem is that if one wishes to pass compiler options to the
C/C++ compiler, none of the flags supported by the build tool seem to support that. 

An example workaround is to run:

    "CC=gcc <flag1> <flag2> <flag3>" go build

but it's rather awkward. Something similar how Cgo handles compiler flags, perhaps.

[gopherbot]

Comment 1 by travis.cline:

Might this be added via a -swigflags ?

Attachments:

1. addswigflags.diff (1889 bytes)

[gopherbot]

Comment 2 by travis.cline:

Updated with go test support

Attachments:

1. addswigflags.diff (2595 bytes)

[rsc]

Comment 3:

Labels changed: added go1.3maybe.

[dsymonds]

Comment 4:

Labels changed: added toolchange.

[rsc]

Comment 5:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 6:

Labels changed: added repo-main.

[emidoots]

Comment 7:

Travis,
I don't think -swigflags is a good choice. Consider that a application depends on
multiple packages that use swig to each wrap an external C++ library; when building the
application you would have to specify -swigflags and pass in each package's
header/library dependencies?
I think a better approach might be to use something like CGO does with it's 'magic'
"#cgo CFLAGS: foo" and "#cgo LDFLAGS: foo" (only adapted for swig) because then compiler
and linker flags could be set per-package and it would be less tedius.
I'm not sure that -swigflags would really have any benifits over the example workaround
from the OP.
Stephen

[alberts]

Comment 8:

Also just ran into this. I would like the ability to set something like CGO_CFLAGS and
CGO_LDFLAGS when building my SWIG package.

[emidoots]

Comment 9:

My proposed CL is at:
https://golang.org/cl/96320043

[gopherbot]

Comment 10:

CL https://golang.org/cl/96320043 mentions this issue.

[gopherbot]

Comment 11 by ivar.gaitan:

I also struggled a bit with this.
Then I found out that the swig build chain uses the flags set by cgo. So by adding a
dummy file alongside the .swigcxx with only #cgo directives and import "C", cgo will be
invoked prior to swig, and the flags you set with #cgo will be passed on to your swig
build.

[steeve]

Comment 12:

Not all of them though, only -I

[michael-schaller]

@slimsag
Stephen, do you think you can update the patch for the Go 1.5 release?
FYI: The Go master seems to have currently issues with SWIG only packages. See issue #9410 for details.

[emidoots]

@michael-schaller

Yes, I'll do my best to get it in ASAP and before the Go 1.5 feature freeze. I will prioritize it and hopefully have it in before (or around) Jan, 1st.

[michael-schaller]

@slimsag
Awesome. I'm happy to test it. Could you also add swigopts so that one can pass custom options like -Wall -Werror to SWIG?

[michael-schaller]

@slimsag
Stephen, do you still have plans to get this in before the Go 1.5 feature freeze?

[emidoots]

@michael-schaller apologies for my latency on this issue.

I've just checked and we do not need to do anything to support this use case anymore.

Since SWIG code is now built using CGO instead of the old plan-9 C compilers, you can simply use a build.go file containing import "C" and #cgo key: value directives as part of your package containing the .swig file. I've put together a simple example to demonstrate this (see below).

At this point, unless there is opposition to using the #cgo directives in combination with SWIG code for some reason, we can close this issue.

$ tree
.
├── main.go
├── mylib
│   ├── build.sh
│   ├── mylib.c
└── mypkg
    ├── code.c
    ├── mypkg.go
    └── mypkg.swig

2 directories, 6 files

The main.go program is very simple (and external from the SWIG wrapper package):

$ cat main.go
package main

import "cflags/mypkg"

func main() {
  mypkg.DoStuff()
}

mylib is a simple C dynamic library I built:

$ cat mylib/build.sh 
gcc -c -Wall -Werror -fPIC mylib.c
gcc -shared -o libmylib.so mylib.o

$ cat mylib/mylib.c
int mylib_add(int a, int b) {
    return a + b;
}

Then I declared a simple C function in the SWIG package to retrieve a preprocessor-defined value (see -DGENERIC_VALUE=32 below):

$ cat mypkg/code.c 
int generic_value = GENERIC_VALUE;

int get_generic_value(void) {
    return generic_value;
}

The SWIG package has the grunt of the code and our #cgo build directives:

$ cat mypkg/mypkg.go
package mypkg

// #cgo CFLAGS: -DGENERIC_VALUE=32
// #cgo LDFLAGS: -L${SRCDIR}/../mylib/ -lmylib
import "C"

import "log"

func DoStuff() {
    // Test that the GENERIC_VALUE defined in the C compiler flags is correct.
    v := Get_generic_value()
    if v != 32 {
        log.Fatal("got unexpected value")
    }
    log.Println("got the right value", v)
    log.Println("mylib_add(2, 2):", Mylib_add(2, 2))
}

$ cat mypkg/mypkg.swig 
/* A trivial example of using CGO compiler flags with SWIG.  */

int get_generic_value(void);

int mylib_add(int a, int b);

Build and run it:

cd mylib/
./build.sh # builds libmylib.so
cd ..
go build # builds the main program binary named 'cflags'

# run the program with libmylib.so on LD_LIBRARY_PATH:
LD_LIBRARY_PATH=mylib/ ./cflags

which produces:

2015/04/02 12:22:27 got the right value 32
2015/04/02 12:22:27 mylib_add(2, 2): 4

[ianlancetaylor]

Thanks for the worked example.

[michael-schaller]

@slimsag
Stephen, thank you for testing this. I gave my code also a test run and I confirm that it works fine with current Go 1.5 and SWIG 3.0.6 snapshots. In the past I still needed a dummy .cpp file for cgo to properly link against a C++ library wrapped with SWIG. With the current code this workaround is no longer necessary. Awesome! :-D