[Question] How do you do automated tests for emscripten builds using googletest?

[mcbarton]

I'm trying to add automated emscripten tests to a project I work on in a PR here compiler-research/CppInterOp#483 . I managed to get Google Test to successfully build and run without error on Emscripten as can be seen here https://github.com/compiler-research/CppInterOp/actions/runs/13006358705/job/36274044251#step:9:279 , but non of the tests appear in the Google Test run. Can someone provide me with a minimal example of how to use Google Test with Emscripten? The only example I have been able to find is here https://github.com/jprendes/emscripten-dylink-demo . It is a few years old and looks out of date since it uses the deprecated compiler setting RUNTIME_LINKED_LIBS . Looking for a more up to date example to guide me.

[sbc100]

Are you using the main function from google test? How does your problem manifest? Does it run the main function but not find any of your tests? Or does the main function not run at all?

We do have a test in the test suite that ensure that googletest does work:

emscripten/test/test_other.py

Lines 14624 to 14634 in 1b46dde

	@is_slow_test
	def test_googletest(self):
	# TODO(sbc): Should we package gtest as an emscripten "port"? I guess we should if
	# we plan on using it in more places.
	self.emcc_args += [
	'-I' + test_file('third_party/googletest/googletest'),
	'-I' + test_file('third_party/googletest/googletest/include'),
	test_file('third_party/googletest/googletest/src/gtest-all.cc'),
	test_file('third_party/googletest/googletest/src/gtest_main.cc'),
	]
	self.do_other_test('test_googletest.cc')

.

[mcbarton]

Thanks for your speedy response @sbc100 . I've tried both with and without a main function defined. When I include main I try including the following file in the compilation of the MAIN_MODULE https://github.com/jprendes/emscripten-dylink-demo/blob/master/src/main.cpp (this is not currently in my PR mentioned above). No matter what I seem to do I get the same result that is shown in the workflow run I link. To me it looks like it tries to run the tests, and says everything passes, but no tests are actually run.

[sbc100]

I would avoid MAIN_MODULE if you can an just stick to static linking.

[mcbarton]

Currently the library we build and link to only works if we build it as a shared library (although there is work being done to hopefully get a static library build in the future) . Is there any way you could suggest I try and link to this shared library without using main_module? I did try and avoid the use of main_module but couldn't find a solution. This is coming trom someone who has only been working with emscripten for a few months now, and still pretty much a novice.

[sbc100]

No, if you have a shared library then you need to build with MAIN_MODULE.

Can you write some simple gtests that do not use dynamic linking, just to confirm that that is needed the problem?

[mcbarton]

I managed to get GoogleTest to run with my emscripten build, but when it tries to run the tests it fails to file the new header file. What compile and/or link flags might I need for a main_module so that it has access to the standard library header files?

[sbc100]

Take a look at https://emscripten.org/docs/api_reference/Filesystem-API.html. Basically emscripten programs run with a virtual filesystem that you can populate in various ways. If you are running on node you can bypass this using -sNODERAWFS, but if you want to run on the web you will need to populate the VFS somehow.

[sbc100]

I assume this is because he program you are testing is itself a compiler and its looking for the new header? What compiler is it? Which version of new to you want to to see? Are you are trying to run emscripten itself inside of emscripten, or are do you want to bundle libc++ from clang directly perhaps?

[sbc100]

Regardless its sounds like the problem is no longer related to gtest, but other things, so maybe this issue can be closed?

[mcbarton]

Thanks for the information. I'll try and apply your suggestions and see how I get on, opening up another more targeted issue if I cannot fix. I'll close this issue with this message.

I'll take the start of the readme from the project to explain what the project I work on is (since I feel it explains it better than I could)

CppInterOp exposes API from [Clang](http://clang.llvm.org/) and [LLVM](https://llvm.org/) in a 
backward compatible way. The API support downstream tools that utilize interactive C++ by 
using the compiler as a service. That is, embed Clang and LLVM as a libraries in their 
codebases. The API are designed to be minimalistic and aid non-trivial tasks such as language 
interoperability on the fly. In such scenarios CppInterOp can be used to provide the necessary 
introspection information to the other side helping the language cross talk.

Not sure which will be the best approach in this circumstance, but your comments point me where to look. Again thanks for the help.