Open HDembinski opened 5 years ago
The last one should be handled, since I added support for test arguments to boost_test
. I however consider the current "parser"'s simplicity a feature, because it allows me easily to skip tests I don't want boost_test_jamfile
to handle - I then write them by hand in CMakeLists.txt
. As long as there are few exceptions, it's not a burden.
It would be easy to also handle [ run test.cpp ]
I suppose, but this may not be desirable if the test suite is declared explicit, which is why I've left it out.
The last one should be handled
Yes, my bad.
I however consider the current "parser"'s simplicity a feature, because it allows me easily to skip tests I don't want boost_test_jamfile to handle
I thought of adding a BLACKLIST argument for tests that should not be handled automatically. But I am unsure whether it is worth spending more time on making the jamfile parser more sophisticated.
I started working on an improved Jamfile parser for
boost_test_jamfile
.The new version should recognize the following tests
I think it would be much easier to write the parser in Python and call it from CMake than implementing the logic with CMake capabilities. Would that be a show-stopper? And is it really useful to have an imperfect Jamfile parser in CMake? An alternative is to provide a Python script which generates the whole CMakeLists.txt from an existing Jamfile.