Re: [boost] Boost Cmake Modules

Subject: Re: [boost] Boost Cmake Modules
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-14 06:00:07

>> 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.cmake#L9
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/