SWIG and CFLAGS/LDFLAGS

[Stephen Gutekanst]

I think this is issue 6696.

CGO has some 'magical' comments we can use to specify compiler/linker flags:

// CGO CFLAGS: someflags 

// CGO LDFLAGS: -lsomelib

Which is important because it lets us specify native system libraries to link against without having to copy the entire source code into the Go package source directory. The closest thing we have for SWIG is something like:

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

Which works well but it requires specifying the compiler/linker flags for every package using SWIG. If a project uses many SWIG packages wrapping native libraries then this can quickly become very tedious and cause people to write bash scripts to do the work, but I think the go tool should handle it somehow.

What are my options to make a SWIG Go package go-get'able when they use native libraries? I am interested in trying to submit a CL for this issue but I would have to know what the acceptable fix would look like:

1. Someone proposed an idea in the form of -swigflags to the 'go build' command, but it suffers from the same problem with many native libraries (of having to specify each one on the command line). I don't this is a good solution.
   
2. SWIG packages require a blank .go source file in this to stop the Go tool from saying "No Go source files in package directory". We could check that source file for CGO-like magic comments, but it would require parsing at least those comments:
1. src/mypackage/swig.go:
2. // SWIG LDFLAGS: -Lfoolibs/ -lfoo
3. // SWIG CFLAGS: -Ifooheaders/
3. Add support directly to SWIG for specifying some linker/compiler flags directly inside .swig files (in which case perhaps their ML would be the proper place to discuss?).

I didn't want to discuss on the bug-tracker, so I created a topic here. I hope that's alright.

Stephen

[Ian Lance Taylor]

I would have the go tool look inside the .swig file for magic
comments. That is essentially how cgo works. We know that every
package that uses SWIG must have a .swig file, so it doesn't require
adding anything new. I would use comments so that SWIG itself doesn't
have to change.

Ian

[Stephen Gutekanst]

Thanks Ian, that's exactly what I needed to know. Don't know how I didn't think of that possibility.

I've got an implementation working right now. But I have another question if you have time: The SWIG docs say:

C and C++ style comments may appear anywhere in interface files. In previous versions of SWIG, comments were used to generate documentation files. However, this feature is currently under repair and will reappear in a later SWIG release.

And I haven't looked at the C/C++ comment specification yet and don't know if there is trickery involved or if comments are just:

// comment

 and 

/* multi-line-comment */

Would it be more appropriate to parse C/C++ comments (and multi-line ones) by specification and scan over that information for the magic #swig lines? Or we could restrict it to something along the lines of:

#swig lines may only occur on lines in the top of the .swig and .swigcxx files on single-line comments ("// #swig ...") preceded by only other single-line comments.

Which would simplify the parsing implementation significantly. But which is more appropriate in your opinion?

Stephen

[Ian Lance Taylor]

On Mon, May 12, 2014 at 6:41 PM, Stephen Gutekanst
<stephen....@gmail.com> wrote:
>
> I've got an implementation working right now. But I have another question if
> you have time: The SWIG docs say:
>>
>> C and C++ style comments may appear anywhere in interface files. In
>> previous versions of SWIG, comments were used to generate documentation
>> files. However, this feature is currently under repair and will reappear in
>> a later SWIG release.
>
>
> And I haven't looked at the C/C++ comment specification yet and don't know
> if there is trickery involved or if comments are just:
>>
>> // comment
>>
>> and
>>
>> /* multi-line-comment */

That is the comments syntax, yes.

> Would it be more appropriate to parse C/C++ comments (and multi-line ones)
> by specification and scan over that information for the magic #swig lines?
> Or we could restrict it to something along the lines of:
>>
>> #swig lines may only occur on lines in the top of the .swig and .swigcxx
>> files on single-line comments ("// #swig ...") preceded by only other
>> single-line comments.

I think that restriction is fine. Since the file is a SWIG file
anyhow, I would suggest using #go instead of #swig.

Ian

[Stephen Gutekanst]

Ok. And good point with #go syntax instead of #swig.

Thanks again!

[Stephen Gutekanst]

For the record my CL is at:

    https://codereview.appspot.com/96320043