Boost logo

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/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk