FAQ
For fun, I've written a small library in C, to be used in an embedded C
system.

After poking around with a few C unit-test libraries, I decided to test
using go's "cgo"+"testing" packages as a way to learn the language.

Though I'm currently blocked on Issue 4030<https://code.google.com/p/go/issues/detail?id=4030> to
have cgo working, it looks like<https://code.google.com/p/go/issues/detail?id=4030>the testing library prevents users from importing the "C" package.

I understand that the testing package is built for golang unit tests, and
it's a good practice to prevent users from using C from the tests that are
meant to isolate their code, but this prevents me from being able to
directly test my C code.

I've written a short .go file (and unit tests for it), but would prefer not
to maintain the extra code.

// sample line from the .go file:
// ...
import "C"

func Call_c_foo() int {
  return C.foo()
}

Is there a better/recommended way of doing this?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Jan 9, 2014 at 3:30 am

    On Wed, Jan 8, 2014 at 2:01 PM, Shale Craig wrote:

    For fun, I've written a small library in C, to be used in an embedded C
    system.

    After poking around with a few C unit-test libraries, I decided to test
    using go's "cgo"+"testing" packages as a way to learn the language.

    Though I'm currently blocked on Issue 4030<https://code.google.com/p/go/issues/detail?id=4030> to
    have cgo working, it looks like<https://code.google.com/p/go/issues/detail?id=4030>the testing library prevents users from importing the "C" package.

    I understand that the testing package is built for golang unit tests, and
    it's a good practice to prevent users from using C from the tests that are
    meant to isolate their code, but this prevents me from being able to
    directly test my C code.

    I've written a short .go file (and unit tests for it), but would prefer
    not to maintain the extra code.

    // sample line from the .go file:
    // ...
    import "C"

    func Call_c_foo() int {
    return C.foo()
    }

    Is there a better/recommended way of doing this?
    I'm afraid there isn't better alternatives. Essentially you will have two
    files,
    pkg_test.go for tests, and another normal go file that do the cgo
    interfacing.

    However, if you take a look at $GOROOT/msic/cgo/test, you will see that
    the trick is this:
    // pkg_test.go
    package pkg
    import "testing"

    func TestSomething(t *testing.T) { testSomething(t) }

    // pkg.go
    import "C"
    import "testing"

    func testSomething(t *testing.T) {
        // now you can use both C.xxx and t.
    }

    If organized this way, all it costs is one extra "wrapper" function for
    each test.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 8, '14 at 10:27p
activeJan 9, '14 at 3:30a
posts2
users2
websitegolang.org

2 users in discussion

Shale Craig: 1 post Minux: 1 post

People

Translate

site design / logo © 2022 Grokbase