The way it scales is that it makes use of directory structure. So if you fire .cpp files into /test, each is considered a ctest target, but if you put them into /test/somedir they get new semantics. In particular, you'll see Boost.AFIO v2 uses a /test structure which says to use Boost.KernelTest which is a new meta-test infrastructure. That will work for the common case. I assume fail test when is based on if the name has fail in it. But how do you handle setting flags for certain tests? Compile-only tests? KernelTest takes care of runtime failure testing (indeed, that's its main purpose, it systematically checks all failures fail as documented).
As documented? Where or how would the user specify that the test should fail?
https://github.com/ned14/boost.afio/blob/master/test/tests/file_handle_creat... Note the tables of initialiser lists of preconditions, API calls and postconditions. That's KernelTest.
In terms of setting flags for certain tests, because it's a 100% target based cmake design, the CMakeLists.txt for the project can very easily set very specific settings for any given individual target. Indeed I just recently mastered creating custom cmake properties which have global, directory and target level overrides. That technique is not well documented, anyone interested please do lift from https://github.com/ned14/boost-lite/blob/master/cmake/BoostLiteSetupP roject.cmake#L9 where you'll see me adding the new CXX properties:
* CXX_EXCEPTIONS * CXX_RTTI * CXX_STATIC_RUNTIME
Those custom properties look quite cool, I always envisioned them being targets in cmake. So when a test needed to disable RTTI, it could just do:
target_link_libaries(my_test disable_rtti)
Using custom properties looks like an interesting approach. I wonder what the pros and cons of using target vs property.
Well, properties are the method by which a target specialises its configuration. Properties have the advantage that you can set them globally, per directory and per target and the property will inherit the nearest setting to the point of use in any newly created targets. That saves a bit of typing and is more "cmakeish". I couldn't figure out how to get per source properties to work right, there was no example in the cmake source code :(
I don't see how submodules can be used for dependency management at all. If library A and library B uses zlib, then using submodules you would need to download and build zlib twice to use both libraries.
The platform's package repos take care of those dependencies. And their security updates.
Plus, there is no way to use the system or a user's build of zlib either. Submodules work nice for superprojects, such as boost or llvm, but it is no solution to dependecy management.
Dependencies aren't all in one category. Stuff like zlib are almost system libraries. You don't need to pin to specific commits of zlib. If you do need to pin to specific commits, git submodules are a great dependency management solution, indeed the best if you're already on git.
I'm not sure about this cget tool, but cmake --build . --target install should work on all platforms after you've done a *recursive* git submodule checkout. By "should" I mean install is not being CI tested yet, and it could be broken after some changes I did earlier this week so caveat emptor. I get an error like this:
-- Found boost-lite depended upon by boost--outcome at embedded include/boost/outcome/boost-lite -- CMAKE_BUILD_TYPE = CMake Error at include/boost/outcome/boost- lite/cmake/BoostLiteUtils.cmake:148 (file): file failed to open for reading (No such file or directory):
/home/paul/tmp/cget/cget/build/tmp- 48d80d9e2c734b86800806772ac60260/boost.outcome/include/boost/outcom e/bo ost- lite//home/paul/tmp/boost.outcome/.git/modules/include/boost/outcom e/bo ost-lite/HEAD Call Stack (most recent call first): include/boost/outcome/boost-lite/cmake/BoostLiteUtils.cmake:188 (git_revision_from_path) include/boost/outcome/boost-lite/CMakeLists.txt:18 (UpdateRevisionHppFromGit) That's an unusual error. It's like the .git file has an absolute path in it.
Can you tell me the contents of the file at /home/paul/tmp/cget/cget/build/tmp- 48d80d9e2c734b86800806772ac60260/boost.outcome/include/boost/outcome/ boost-lite/.git please?
$ cat /home/paul/tmp/cget/cget/build/tmp- 48d80d9e2c734b86800806772ac60260/boost.outcome/include/boost/outcome/bo ost-lite/.git gitdir: /home/paul/tmp/boost.outcome/.git/modules/include/boost/outcome/boost- lite
As suspected, you've got absolute paths in your .git file. I've never seen that in the wild before. I'll fix the cmake to inspect the path and that ought to fix that problem at least. Thanks for the bug report. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/