Improve command-line options handling in ToolTest.cc

[lahwaacz]

ToolTest.cc has terrible handling of command-line options:

orc/tools/test/ToolTest.cc

Lines 37 to 58 in 1d33d2a

	GTEST_API_ int main(int argc, char** argv) {
	GOOGLE_PROTOBUF_VERIFY_VERSION;
	std::cout << "ORC version: " << ORC_VERSION << "\n";
	if (argc >= 2) {
	exampleDirectory = argv[1];
	} else {
	exampleDirectory = "../examples";
	}
	if (argc >= 3) {
	buildDirectory = argv[2];
	} else {
	buildDirectory = ".";
	}
	std::cout << "example dir = " << exampleDirectory << "\n";
	if (buildDirectory) {
	std::cout << "build dir = " << buildDirectory << "\n";
	}
	testing::InitGoogleTest(&argc, argv);
	int result = RUN_ALL_TESTS();
	google::protobuf::ShutdownProtobufLibrary();
	return result;
	}

First, it interprets argv[1] as exampleDirectory and argv[2] as buildDirectory. Then it passes all options to testing::InitGoogleTest(&argc, argv);

This means that passing optional arguments like --gtest_* does not work. If I do

gtest_filter="-TestMatchParam/FileParam.Contents/19:-TestMatchParam/FileParam.Contents/23"
build/tools/test/tool-test --gtest_filter="$gtest_filter"

then all tests except one fail with an error like

C++ exception with description "Can't open --gtest_filter=-TestMatchParam/FileParam.Contents/19:-TestMatchParam/FileParam.Contents/23/TestOrcFile.testDate2038.orc" thrown in the test body.

[dongjoon-hyun]

Any suggestion or working PRs? This is open source community. You can contribute in a way you want to expect to be.

[lahwaacz]

The testing::InitGoogleTest(&argc, argv); should be done first as it will remove gtest options from argv: https://stackoverflow.com/a/4820180

Then see if you need to do anything special about parsing the remaining arguments...

[dongjoon-hyun]

Sure. Since this is an open source project to open to all suggestions, feel free to open a PR if you want to make it in that way. We can continue to discuss on your PR.

The testing::InitGoogleTest(&argc, argv); should be done first

In general, for the proposal about test code, we can easily adopt the new way. I hope the proposed change is concise and small.

[WillAyd]

Now that we have added Meson support, this manifests itself when running the test suite and using Orc as a subproject, rather than the main project being built. I think this tests ends up resolving the build directory to the main project, and therefore the tests are unable to find the executables.

Here's an example of that from the logs:

https://github.com/mesonbuild/wrapdb/actions/runs/15763207309/job/44434342657?pr=2206#step:4:27298

Will take a look at this in more detail

[WillAyd]

I wonder if instead of trying to get these argument from the command line, it might be better for the build system to pass along its build directory location and the source location of the examples directory

[WillAyd]

This should be closed by #2291

[dongjoon-hyun]

Thank you, @WillAyd . Let me close this issue.

[dongjoon-hyun]

For the record, Apache ORC 2.2.0 will arrive this month. We are actively working on finalizing it, @lahwaacz .