I am now ready to announce Request for Proposals on boost developer's
list and concurrently on reddit/r/cpp. Before I do this I wanted to
clarify some issues and give you all one final opportunity to spit ball it.
a) I've "re-purposed" the boost review process to permit the
simultaneous review of multiple submissions. I just want to make sure
that there is a consensus that this is OK so no one will complain after
I take the leap to open the argument "This is not the traditional
review" or Ramey doesn't have the authority to change boost procedures.
or ...
b) I'm including ron garcia (review wizard) on this email to make sure
that he also OK with this and to ask him to place these proposals in the
queue for review 15 February 2019.
c) I've alluded to the award of a $5000 "prize" to the author of the
selected proposal upon integration into boost. David raised the
question as to trying to make this more flexible to make it more fair
and encourage collaboration. Do this would put the review manager (me -
unless you've got some one stupider than I am with a death wish to take
on the task) in a sort of impossible situation of trying to create
"fairness" where none is possible. One of the great virtues of the
boost review process is that the reviewer must actually make a thumbs
up/down decision. The avoids the situation where he gets sucked into
the library design by accident. It forces all the participants to get
their licks in during the review - knowing that it will be a definite
discussion ending decision. It may not be perfect, it many not be fair,
but it's better than the alternative. It's like plastic surgery,
perfect always ends up worse than better.
d) Right now the prize is unfunded. I've got 3 months to address this.
It's my plan to solicit sponsors for this award in the amount of $1000
each. I'll be pitching: Boost, C++ alliance, Kitware and previous
sponsors of C++Now. I envision this working in the following manner.
Payments are made to the Boost account at the software conservancy to
the amount of $6000. They take their cut off the top and cut a check
when requested for $5000. You'll have to decide on the mechanics.
Speak now, or forever hold your peace.
Below is the document I plan on publishing.
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. After reading this
document:
1) A library user should be able to incorporate a Boost Library
into the CMake script of an application which uses the Boost library in
question.
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. So a library author with no
background in CMake should be able to add CMake support to his library
in a short time - on the order of an hour.
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/demonstrating that this expection is realized 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 as expected. 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. It will also provide a
template/example for Boost Library developers endeavoring facilitate the
usage of their libraries by users of CMake.
e) A commitment to support the submission, should it be accepted, for
a period of 5 years after integration into Boost. Such support would
include fixing bugs, updating documentation as necessary, and triaging
of pull requests.
d) a Boost License
Scope - 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) 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.
*f) 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 a library should not alter the source tree.
*3) no need for installing libraries not used by the library
*4) there should be no conflicts with other files. In particular,
any implementation should not hinder the usage of the boost.build.
g) 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) testing should be available to both library users and library
developers
5) should not depend upon tools other than a C++ and of course
CMake itself.
6) test should have the option of posting the results to some
public "dashboard" which can be browsed by other users and library
developers.
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.
8) Any build/test facilities should take into account the compiler
features as revealed by the tests for the boost/config library. This is
required to support the portability/universality which is one of the
hallmarks of the Boost Libraries.
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) Some have suggested a highly automated process including
downloading/updating, finding other components on other machines, etc.
Overly elaborate/opaque submissions will not be well received.
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. Submitters will be notified of acceptance or rejection
as soon as practicable.
b) When authors are believe that their submissions are ready for review,
they shall notify the reviewer at ramey at rrsd dot com. The
submissions will be verified to meet the requirements and minimum scope
as described above. Authors will be advised of any deficiencies and
given a chance to correct them. When the review period starts, all
information on submissions will be posted on the Boost Developer's
mailing list.
c) The boost review process is described at www.boost.org . This
instance will deviate from that description in that we will review all
submissions simultaneously and select the one we would like to see
incorporated into boost. Other than it should be the same as the normal
boost review process.
c) The boost review process occurs on the boost developer's mailing
list. Authors of submissions should be subscribers to this list. Boost
custom is that subscribers use their real names. Its' been found that
leads to more productive discussion and effectively eliminates the
participation of trolls. Even so, discussions can get animated, but
generally things are carried out in a civilized level. However, if
submitters desire to use an anonymous handle on the mailing list they
are free to do so. We understand that one might want to do this for any
number of personal reasons which are no one else's business.
d) Submissions will be closed on or about 15 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. If 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 to fulfill
the conditions 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,
aggravation of this task and commitment to future support. 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/
All boost discussions regarding CMake
http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2600599&query=subject%3ACMake&days=0&sort=date
Robert Ramey
--
The Boost Steering Committee webpage:
https://sites.google.com/a/boost.org/steering/
---
You received this message because you are subscribed to the Google Groups "Boost Steering Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/boost-steering.
To view this discussion on the web visit
https://groups.google.com/d/msgid/boost-steering/06ac0ec7-799c-afd1-222a-f5d69d42ad22%40rrsd.com.
For more options, visit https://groups.google.com/d/optout.
