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

Subject: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-18 20:43:52

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

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
======================

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.

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

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

     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

  *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
     4) should be available to both users and developers
     5) should not depend upon tools other than C++.
     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.

   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".
    *2) building out of tree
    *3) no need for installing libraries not used by the build target

  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.

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.

Useful Resources
===============
      “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
      https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
      https://github.com/purpleKarrot/Boost.CMake
      https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/