Re: [boost] Boost Cmake Modules

Subject: Re: [boost] Boost Cmake Modules
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-20 06:15:27

>>>> 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_create_close/runner.cpp

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/