On Sat, 2017-01-14 at 11:00 +0000, Niall Douglas wrote:
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?
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/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.
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 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. 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.
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 don't see how having it installed as a system library negates the need for `find_package`. If I say `find_package(boost_filesystem)` then it will automatically link its dependencies(like Boost.System) for me. Installing it with a system package manager without installing the find_package files, would require the user to manually figure out the dependencies. This is what the FindBoost module does currently in cmake. Since this is a manual process, it requires updating cmake to support newer versions of boost. Instead, libraries like boost should provide the cmake find_package files(even when its installed by the system package manager).
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
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