Re: [boost] Draft copy - Call for Submissions - CMake for Boost

Subject: Re: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-10-23 21:35:39

On 18.10.18 22:43, Robert Ramey via Boost wrote:
> The following is a draft of the document of I have planned to post on 
> behalf of Boost on or around 1 November 2018 as the first step in our 
> next attempt to accommodate CMake in Boost.
> 
> Robert Ramey

I have a couple of questions and remarks, inline.
Maybe there is a newer revision?

> 
> 
> Call for Submissions - CMake for Boost
> ======================================
> 
> For some time, there has been interest on many users and developers of 
> Boost Libraries to make Boost easier to use with CMake. Discussions in 
> the past have not resulted in an implementation which has been widely 
> accepted.  Never the less, hope springs eternal, and we intend to 
> attempt this once again.  It seems that often there are difficulties 
> before such projects even start in that there are wide discrepancies as 
> to what should be the goals and expectations of Boost support of CMake. 
> The aim of this document is to try to build a consensus on this question 
> before encouraging CMake developers and experts to submit proposals for 
> Boost support of CMake.
> 
> Requirements and Scope
> ======================

Where is the scope of the submission explained?

> 
> Requirements
> ------------
> 
> Submissions will fulfill the applicable requirements of any boost 
> submission.  This will include:
> 
>  Â  a) any necessary code.
> 
>  Â  b) specifications/requirements for things like directory structure 
> and contents.
> 
>  Â  b) A useful document. Document should provide information, examples 
> and templates so that a typical C++ and CMake user should be able to do 
> any of the following in a short time - say 10 minutes.  Document at a 
> minimum should be viewable as html and/or PDF file.

Can this be a few wiki pages on Github as well? I started looking at the 
way CMake builds its own documentation, and I believe this is overkill.

>  Â Â Â  1) A library user should be able to incorporate a Boost Library 
> into the CMake script.

Does b2 do that? I personally always used b2 for installing boost within 
a prefix and then using it from there.

CMake contains already the FindBoost module:

- Is the intent here to be able to replace CMake's FindBoost it with our 
own?
- Should that be on a freshly cloned repository without prior build step?

I am not found of this idea. I would rather focus on improving FindBoost 
in CMake for library users and stick to the current workflow: 
build/install boost, then source boost.

Also, there are different ways of incorporating. I am pretty sure that 
there are very conflicting opinions on this.

 >      2) A library user should be able to determine which additional
 > Boost Libraries he needs.

Does he? If I need boost.test, as a library user I do not care about the 
dependencies of boost.test.

>  Â Â Â  3) A library developer should find it simple to create the 
> requisite CMake files for his library.  Thus the documentation should 
> contain explanation and perhaps other means such as examples and/or 
> "templates" for required CMake files.
> 
>  Â  c) test of CMake facilities supported by the CMake implementation. 
> This will include code, test of any features, capabilities that the 
> submission provides. Users expect that if they follow the instructions 
> in the documentation, they will get the promised results.  A manner of 
> proving this must be provided.  A likely response to this requirement 
> would be a "test project" which can be used to demonstrate that the 
> submission actually works.  This will be useful in the future for 
> maintenance of the CMake Boost implementation. It will permit the 
> maintainer of the Boost.CMake facility to work on and test their fixes 
> and improvements without disrupting other developers and users.
> 
>  Â  d) a Boost License
> 
> Facilities and features
> -----------------------
> 
> CMake as it stands has lots of capabilities.  But it has a fair amount 
> of complexity as well.  Lots of things can be accomplished in multiple 
> different ways - each with subtly different results and effects.  CMake 
> for Boost will likely consist of documentation, examples, CMake code, 
> and other stuff to use CMake to permit new features and facilities for 
> users and developers of Boost libraries.
> 
> What follows is a list of facilities that Boost users and developers 
> would like to acquire with CMake for Boost.  Those marked with * should 
> be considered hard requirements.  That is, submissions which don't 
> include this feature can't be considered.  Other items are interesting 
> and would be considered if included in a submission.
> 
>  Â *a) incorporating selected Boost Libraries into a user's application

There are some libraries in Boost for which having a CMake/b2 one-to-one 
feature mapping is close to impossible with CMake (without hacking CMake 
at least).

So what do you mean by "incorporating"? Should that cover all the 
possible use cases that currently b2 offers?

> 
>  Â *b) incorporating selected Boost Libraries into a user's library
> 
>  Â  c) building a boost library
> 
>  Â  d) building a boost tool such as Boost.bcp, Boost.boostdep, etc.
> 
>  Â  e) testing a boost library - if testing of Boost libraries is to be 
> supported, the following features should be considered.  Those marked * 
> should be considered essential.
>  Â Â  *1) execution tests - must pass/ must fail
>  Â Â  *2) compile only tests - must pass/ must fail
>  Â Â  *3) link only tests - must pass/ must fail

Do we have link only tests in b2? Can somebody point me to an example?

>  Â Â Â  4) should be available to both users and developers
>  Â Â Â  5) should not depend upon tools other than C++.

Building documentation for instance requires other tools.

>  Â Â Â  6) test should have the option of posting the results to some 
> public "dashboard"
>  Â Â Â  7) option for recursive testing and/or building of libraries might 
> be nice.  That is if library A uses library B and I test library A, this 
> would automatically test library B beforehand.
> 
>  Â *f) In CMake, dependent libraries are specified as part of the library 
> CMakeLists.txt files.  There several ways to do this and the subject is 
> pretty confusing to get right.  Any submission documentation has to 
> explain to library developers how do this.

I would like to remove "CMakeLists.txt" here, as this is part of the 
implementation.

Also, few libraries are needing external libraries for compilation. I 
have in mind GIL that can work with JPEG/TIFF/PNG external libraries.
If CMake offers facilities for sourcing the external dependencies, those 
should be favored (for instance find_package(JPEG)).

> 
>  Â  g) Some have suggested a highly automated process including 
> downloading/updating, finding other components on other machines, etc. 
> This shouldn't be considered
> 
>  Â  h) packaging - preparation of distributable, installable files for 
> various operating systems. That is support for the CPack facility.
> 
>  Â  i) There has been a lot interest and work in automatically 
> determining dependencies It's a much deeper subject than most people 
> realize.  Solving this problem is not a requirement of the submission. 
> However, submitters are free to address this if they desire.
> 
>  Â *j) support of library modularity. This would mean:
>  Â Â  *1) independence of things outside the library directory structure. 
> To wit - no presumption about any "super project".
I do not understand here. I believe this deserves an example.
(of course, I understand what a superproject is, but as soon as there is 
a dependency within libraries, then a library should somehow know about 
its dependencies, which means that a higher level is orchestrating.)

>  Â Â  *2) building out of tree
Is this relevant?

>  Â Â  *3) no need for installing libraries not used by the build target

Do you mean "... build targets and any of its dependencies"?

> 
>  Â k) ...
> 
> Submission Rules and Procedures
> -------------------------------
> 
> a) This document constitutes a "Request for Submissions".  It will be 
> announced on the boost announcements list, boost developer's list, 
> slack/boost, isocpp website and twitter account, reddit at r/cpp. 
> Submissions will be open to anyone.
> 
> b) Submissions will be accepted at an email address to be specified. 
> Received submissions will receive a "prescreening" to determine that 
> they meet the requirements specified for such submissions at the top of 
> this document.  Those that don't will be returned to the author.

There are so many ways to misinterpret things in the requirements, would 
the prescreening be open some time before the submission deadline?

> 
> c) The name of the author of a submission will not be included in the 
> submission.  Authors will be expected to take reasonable efforts to 
> maintain his anonymity via a github repo without a real name assigned, 
> anonymous, email address etc.  We understand that the nature of the 
> submission and debate during subsequent review of the proposals.  Never 
> the less we believe that anonymity can be mostly maintained. The the 
> true identity of the author of the selected proposal will not be 
> revealed until the selection is made.
> 
> The motivation for this anonymity is to attract submitters who find the 
> boost review process distressing, annoying and/or unpleasant. It should 
> also address the concerns of those who beleive that by not being a 
> "boost insider" they won't get fair consideration.  Boost is first and 
> foremost a meritocracy.  We seek the very best in everything regardless 
> of other considerations.
> 
> d) Submissions will be closed on or about 1 February 2019.  Boost formal 
> review will commence shortly there after.  Depending on the number of 
> submissions received, the process may last as long as  month.
> 
> e) As per the boost formal review rules and customs, some time after the 
> review period terminates, the review manager will announce the review 
> results.  This will likely contain some conditions regarding alterations 
> required in the submissions implementations.  I the author find these 
> too onerous, and declines the opportunity to integrate his submission as 
> an official part of boost, the review manager may select an alternate 
> submission.  It's also possible that the review manager may decide to 
> accept none of the submissions.
> 
> f) when the submission is integrated into boost and is shown fulfill the 
> requirements stipulated by the review manager.  The author will receive 
> a "prize" of $5000 and a large but cheap medal on a ribbon hopefully to 
> be awarded at the next C++Now (Boost Con).  As this is written, this 
> prize is subject to finding a funding source.  It's understood that this 
> stipend is in no way compensation, for all the work and aggravation of 
> this task.  But we hope that it will serve as a tangible token of our 
> gratitude for solving one of Boosts most pressing and difficult problems.

What you are suggesting is good to some extent, but it surprises me that 
no body mentioned that: it is a highly competitive submission scheme, at 
the limit of toxic for boost.

You pointed yourself that this is new for boost that we will have 
several submissions for one specific tool. Yet, there are other ways of 
achieving this, don't you think?

I believe that nobody will get it right the first time, and this should 
be a common effort to get there. What you are suggesting is a one-shot 
commitment.

So nothing for collaboration, and nothing for incremental support of cmake.

How can we fix that? I would love to collaborate openly on this.

Raffi