Re: [boost] CMake and Boost Build tests

Subject: Re: [boost] CMake and Boost Build tests
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-26 20:28:51

On 7/26/2017 3:33 PM, Robert Ramey via Boost wrote:
> On 7/26/17 11:49 AM, Edward Diener via Boost wrote:
>> Following John Maddock's appeal for practical solutions related to the 
>> move to CMake, I would like to know what the CMake equivalent is to 
>> the Boost Build unit test functionality.
>>
> I can tell you what I did for the serialization library.  This predates 
> the current discussions so will likely be considered out of date by the 
> current contributors to the discussion.  On the other hand, it does 
> actually work and you can test it yourself.

Robert I appreciate your answer. Is this the CMakeLists.txt in the CMake 
subdirectory of the serialization library ? Remember I am talking about 
header-only libraries where nothing is "built" and I am only trying to 
run the unit tests in the library's 'test' subdirectory using CMake 
rather than Boost Build using CMake's equivalent of a script file rather 
than a Boost Build jamfile.

> 
>> In other words what do I write for CMake in order to do a Boost Build 
>> compile, compile-fail, link, link-fail, run, and run-fail unit tests ?
> 
> One adds targets (which for me is just the name of the source/excutable 
> without the cpp, exe, etc. to a list to get compile and run 
> functionality.  Its pretty simple.

I want to see actual cmake code. Saying "Its pretty simple" only means 
it is pretty simple for those who already know CMake well.

<RANT>

I find the CMake documentation at https://cmake.org/cmake/help/v3.9/ 
nearly impossible to understand due to the fact that there is no 
overriding explanation of how CMake is supposed to work as practical 
examples of setting up CMake scripts. While I realize that all the 
information is supposedly there I have just about no idea how it all 
comes together. I am guessing that the only way I can really learn CMake 
is buying the "Mastering CMake" book, which I don't mind doing so if I 
have to do it. If I am wrong and someone would like to point me to an 
actual overview which explains CMake in a regular and meaningful way, 
rather than a bunch of loosely related topics which is the actual CMake 
documentation in the above URL, it would be appreciated.

</RANT>

> 
> I couldn't make the compile-fail and run-fail targets to work so I just 
> removed them from the cmake test suite.  So if your thinking that CMake 
> has a ways to go to be able to offer what we expect, you're right.

So you are saying that you cannot run a unit test with CMake that is 
meant to show a failure. Wow, what a brilliant system !

> 
>> Does CMake have an equivalent to the Boost Build alias rule ? or the 
>> Boost Build project rule ?
> 
> LOL - I honestly don't remember what these rules do in boost build.  But 
> then I've only been using boost build for 15 years.

The project rule for unit tests is normally used to set usage 
requirements for all tests being run. The alias rule for unit tests is 
normally used as a means of grouping some unit tests together so that 
the end-user of the tests can test individual groups rather than all the 
tests.

> 
>> The great majority of the Boost libraries are header-only libraries 
>> where Boost Build is used to run the unit tests and, 
> 
> true and this case is pretty simple in both cmake and boost build.

Once again saying it is pretty simple in cmake isn't showing me anything.

> 
>> optionally, Boost Build is used to build the documentation using a 
>> quickbook, boostbook, doxygen toolset to generate html and pdf files. 
> 
> Personally, I could never make this tool chain work despite a large 
> investment of effort.  I gave up on doxygen and quickbook after 
> concluding them to be essentially non-functional.  I did manage to use 
> the xml tools loaded with boost tools along with some downloaded FOP, a 
> version of XMLMind to create toolchain which is about 100 times better 
> and 1/100 as complex as the boost one for creating documents.  So you're 
> life will be better when you're forced to leave these behind.

I heartily disagree. Using quickbook and doxygen is a no-brainer for me, 
but there is no point of debating this. Are both perfect ? No. But using 
them makes creating documentation supremely easy.

I did say that there is no Boost requirement for creating documentation 
using Boost Build. Some documentation is straight html. But for those 
libraries that do go the quickbook and doxygen way using Boost Build we 
need a CMake way of doing this if that is what the Boost Steering 
Committee is mandating.

> 
> While I realize that
>> building a Boost library, and making that built library available to 
>> end-users via CMake, has been the focus of most of the discussion so 
>> far regarding CMake and Boost,
> 
> You are correct.  There are two independent issues related to this.
> 
> a) Replacing boost build with cmake
> b)  providing CMake files to be helpful to users who use CMake to build 
> their applications.
> 
> Boost should first address b) first while leaving a) untouched for now. 
> If it can't manage to do that, then there is not point in trying to 
> address b)
> 
>   I am assuming the move to CMake also means that running unit tests
> 
> I think that is the goal
> 
> and building docs where applicable must also be  done through CMake.
> 
> I don't see this as a requirement nor do I see it as necessary or 
> desirable.
> 
>> If I am wrong about this then I personally will be only too happy to 
>> continue using Boost Build to do these things.
> 
> LOL - it certainly looks that way.
> 
> I wouldn't panic yet.  Nothing is actually going to happen until someone 
> actually does something (besides offer advice).  It doesn't seem that 
> that is going to happen very soon, so you can just relax.

OK, I will relax and await the outcome of those, whoever they are, who 
are evidently taking on the work of providing CMake scripts for what is 
currently Boost Build tasks.

> 
> But you might want to experiment a little with the following useful 
> orthogonal ideas.
> 
> a) investigate how CMake Find<your library> should work and consider 
> adding the files necessary to support it to your library.  This wouldn't 
> mess up any of your other work.
> 
> b) Consider making a simple CMake project to build library and run tests 
> such as I did for the serialization library.  CMake gurus it seems 
> dismiss this effort.  But it has worked for me.  The main benefit for me 
> is that permits to to build a working IDE which I can used to build and 
> debug.  For me, this has turned out to be a great time saver.

I do not know how you learned enough of CMake to do what you want but, 
apropos my RANT, I am finding my ability to do this severely hampered by 
the piecemeal documentation which CMake deems its own docs.

> 
> Also I use boost build for running unit tests on my local system and it 
> works very well for that. It's what I really depend on.  It doesn't 
> consume any effort to maintain (it was a MAJOR effort to setup).  And I 
> created my own program to display test results (library_test) so I'm 
> very happy with this.  One thing that CMake has that Boost Build doesn't 
> have is CDash does have is the ability to upload test results to a 
> special site where all test results from all users can be browsed.  This 
> is desperately needed for Boost but no one has made the effort to build it.
> 
> So all in all, I'm hoping that we can evolve to something better and 
> more widely useful.  But I don't see anyone actually undertaking efforts 
> to make that happen.  So I don't think you and I really have to worry 
> about this all that much.  We'll Boost build will likely out live you 
> and me.
> 
> Robert Ramey