On 26/05/2016 04:12, Marvin Humphrey wrote:
With Python distutils as with Perl's Module::Build, it is at least
theoretically possible to provide a list of object files to be linked into the
host extension.
I'm leaning towards the "list of object files" approach for the Perl bindings.
Unless static libraries are really used as intended, they seem to create more
problems than they solve.
But with CGO, I don't know how to do that.
* You can't tell the Go build system about a list of compiled object files.
* You can't tell CGO about arbitrary directories full of C files to compile.
* You *can* put loose C files into the package directory, but only that one
dir -- nested dirs aren't allowed.
* You *can* hack in linker instructions using pseudo `#cgo` directives.
https://golang.org/cmd/cgo/#hdr-Using_cgo_with_the_go_command
We're currently using the last option to tell CGO about the static archive
built using Charmonizer/Make.
Another solution is to add fake references to object files that aren't picked
up when linking with the static library. The only problematic file for me was
TestUtils.o. Object files for non-inert classes are always referenced by the
generated binding code. For inert classes, this could even be automated by
adding a reference to any symbol of an inert class somewhere in the generated
code. This leaves non-Clownfish source files (stuff like LFReg) that aren't
used by the parcel itself which should be a rare case.
What about code like `xs/XSBind.c`? Should it be compiled by the host, too?
Yes, IMO -- it's hard to handle otherwise because you have to know about
installation-specific include dirs and the like.
OK.
Nick
