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). I haven't found a need for compile fail tests yet. But then I tend to expose as static constexpr bool all the logic the metaprogramming uses and those can be static asserted and Expression SFINAE checked as part of a compile. So, in other words, if the compile succeeds then all the compile failure causes were checked (or at least the ones I thought of). I'm not ruling out adding fail tests later, but until now I haven't found a need. 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/BoostLiteSetupProject.... where you'll see me adding the new CXX properties: * CXX_EXCEPTIONS * CXX_RTTI * CXX_STATIC_RUNTIME
Many years ago Stefan (along with Dave Abrahams) championed a new C++ docs tool which was much better than doxygen, but in the end the effort required to finish it proved difficult to make happen. I'm sure most would agree what a shame.
If anybody knows of a tool which can understand doxygen markup but generates much better reference docs, I would be *extremely* interested. The really key part is that new C++ docs tooling *needs* to grok doxygen markup. So many new tools don't, and therefore get no traction because so many C++ codebases are locked into doxygen markup.
Like I mentioned, there is standardese:
https://github.com/foonathan/standardese
It still a WIP, but it looks like it is shaping up nicely.
Ah I remember reading this on his blog a good while back. I'm glad it's "gained legs" judging from its commit history. However, I find the ISO C++ standard not a great way of documenting reference documentation for most libraries. For example, with Outcome it's way overkill, Outcome behaves like the STL, you don't need to explicitly and labouriously say so per API. Just assume it does, and if it doesn't then it's a bug. But for AFIO standardese is a great fit. AFIO needs to specify in very great detail the exact semantics of say read() and write() else users will write erroneous code. Thanks for reminding me of that tool.
However, beyond superprojects, I don't think submodulues are a good way to manage dependencies. Its best to take an approach similiar to llvm. There can be a superproject that has all the components together to build, or each component can be built and installed individually.
git submodules (as of the very latest git) give you wide flexibility in the .gitmodules file to specify all sorts of useful semantics about dependencies. It's not 100% there yet, but getting ever closer to becoming the de facto dependency management system for any git based program. The new shallow clone subrepo facility is particularly useful.
I think this stuff comes back to David Sankel's notion of libraries being anti-social. If you're anti-social, you force library users up this hill of preconfig and build just to test out your library.
All libraries go through the steps of configure, build and install:
cmake .. cmake --build . cmake --build . --target install
Trying to support a non-conventional way to build the library would be anti-social.
Agreed. And that should work with my stuff (though there is one known bug which will be fixed before Outcome enters the review queue).
Furthermore, after I have installed a library I would expect to use it like this:
find_package(YourLib) target_link_libraries(myLib ${YourLib_LIBRARIES})
Not supporting that I would consider anti-social as well. And this is the point of the cmake modules that I am writing is to be able to support this easily especially for boost libraries.
I'm less convinced of the necessity of this when your library is installed as part of the platform's package repos and therefore is now a system library. But in general, I would agree, and it's definitely a nice-to-have.
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/outcome/bo ost- lite//home/paul/tmp/boost.outcome/.git/modules/include/boost/outcome/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? In the meantime, I'll make that bit of the cmake scripting check for a non sane path in .git and bail out more usefully. Thanks for the bug report. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/