Re: [boost] Boost Cmake Modules

Subject: Re: [boost] Boost Cmake Modules
From: paul (pfultz2_at_[hidden])
Date: 2017-01-19 17:51:39

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
>