Proposal Details
I'd like it to be able to build the go tests into a static or shared library, to be linked to an executable and run at a later stage. My use case is to run tests on iOS and Android, where it's not possible (or not easy) to run the go test executables directly, but linking to a library from a native app is reasonably easy.
Currently, go test -buildmode=c-archive/c-shared builds something but due to the way c-archive/c-shared work, the main function is not called, nor callable, and no symbol is exported, so the libraries aren't usable in any way. Also, if you do not pass -c, go test attempts to "run" the library, which fails with confusing error messages.
I know this is a bit of an edge case, so I wanted to see how difficult an implementation would be. Turns out, not very, functional prototype is here: https://go-review.googlesource.com/c/go/+/743741
I also have a small manual test setup here (my prototype is lacking tests): https://github.com/drinkcat/gotest-lib-example
The changes do the following:
- Export functions to run tests with these 2 signatures, the second one overrides
os.args, so we can pass parameters like -test.v:
extern int go_test_main(void);
extern int go_test_main_with_args(int argc, char** argv);
- Also copy the generated
.h next to the .a/.so file.
- If
-buildmode=c-archive/c-shared, imply -c as running a library makes no sense.
Proposal Details
I'd like it to be able to build the go tests into a static or shared library, to be linked to an executable and run at a later stage. My use case is to run tests on iOS and Android, where it's not possible (or not easy) to run the go test executables directly, but linking to a library from a native app is reasonably easy.
Currently,
go test -buildmode=c-archive/c-sharedbuilds something but due to the wayc-archive/c-sharedwork, themainfunction is not called, nor callable, and no symbol is exported, so the libraries aren't usable in any way. Also, if you do not pass-c,go testattempts to "run" the library, which fails with confusing error messages.I know this is a bit of an edge case, so I wanted to see how difficult an implementation would be. Turns out, not very, functional prototype is here: https://go-review.googlesource.com/c/go/+/743741
I also have a small manual test setup here (my prototype is lacking tests): https://github.com/drinkcat/gotest-lib-example
The changes do the following:
os.args, so we can pass parameters like-test.v:.hnext to the.a/.sofile.-buildmode=c-archive/c-shared, imply-cas running a library makes no sense.