Draft copy - Call for Submissions - CMake for Boost

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On Thu, Oct 18, 2018 at 3:44 PM Robert Ramey via Boost <
[hidden email]> wrote:

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


That almost certainly violates the GitHub Terms of Service. As the likely
way to achieve that is to create a duplicate account.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Robert,

On 10/18/18 4:43 PM, 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.

[...]

Quite a number of people (Rene, Edward, myself, ...) have argued in
different ways against a wholesale switch from Boost.Build to CMake.
While for some the point is more about incrementality of the process,
for others it's about autonomy and modularity.

I'm surprised, even shocked, to see that your draft doesn't even mention
modularity as a goal, but again focusses exclusively on the modalities
of an eventual switch. I have said it often, and I'm saying it again:
you can't force a Boost maintainer to adopt a CMake-based build system
for his project. You can only show by example that it works well (by
picking volunteer projects as early adapters), and hope for others to
follow voluntarily (incrementally over the course of a couple of
releases), given that the maintenance burden of that new environment is
entirely on them.

So, I would expect in a RFP to find requirements such as:

* a solution must allow for a heterogeneous environment, where some
Boost libraries are still built with Boost.Build, while others are built
with CMake.

Anything less than that is not going to fly.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 2:15 PM, Stefan Seefeld via Boost wrote:

> Hi Robert,
>
> On 10/18/18 4:43 PM, 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.
>
> [...]
>
> Quite a number of people (Rene, Edward, myself, ...) have argued in
> different ways against a wholesale switch from Boost.Build to CMake.
> While for some the point is more about incrementality of the process,
> for others it's about autonomy and modularity.
>
> I'm surprised, even shocked, to see that your draft doesn't even mention
> modularity as a goal, but again focusses exclusively on the modalities
> of an eventual switch. I have said it often, and I'm saying it again:
> you can't force a Boost maintainer to adopt a CMake-based build system
> for his project. You can only show by example that it works well (by
> picking volunteer projects as early adapters), and hope for others to
> follow voluntarily (incrementally over the course of a couple of
> releases), given that the maintenance burden of that new environment is
> entirely on them.
>
> So, I would expect in a RFP to find requirements such as:
>
> * a solution must allow for a heterogeneous environment, where some
> Boost libraries are still built with Boost.Build, while others are built
> with CMake.

I think this is a necessary conclusion given the other conditions.
Including, but not limited to:

  *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

>
> Anything less than that is not going to fly.

Modularity has been a goal of mine for many years - see Boost 2.0
presentation at C++Now in 2010.  I think that modularity is implied by
the other requirements. I don't think one could fulfill the requirements
without being consistent with "Modularity".  Maybe you should read the
document more closely.

I refrained from explicitly mentioning "Modularity" because I don't and
didn't want this to be a debate about "Modularity".

Robert Ramey

>
>
> Stefan
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
AMDG

On 10/18/2018 02:43 PM, Robert Ramey via Boost wrote:

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

  I don't see how this makes sense.  For the most part,
the code itself will be sufficient to identify the
author (at least for those of us who have been
following the discussions of CMake for a while).
If the code weren't enough, the authors would give
away their identities in the discussion
- Either they use their real names in the discussion and
  we can spot who is defending their own decisions or,
- They use anonymized names which we can match with their
  real names by their (well-known) idiosyncrasies.
(Of course, I'm assuming that the submissions are mostly
coming from the usual suspects.  Otherwise, we won't
know who they are anyway, so making it anonymous is
pointless.)

> The motivation for this anonymity is to attract submitters who find the
> boost review process distressing, annoying and/or unpleasant.

This seems like a bad idea, given that we would
expect more than a hit-and-run from the submitter.

> 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.
>
In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, 18 Oct 2018, 22:44 Robert Ramey via Boost, <[hidden email]>
wrote:

>
>    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++.
>

plus, cmake and ctest programs and their infrastructure.

May be worth mentioning to make the point clear w/o any doubt.

Mateusz Loskot, [hidden email]
(Sent from mobile)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/18/18 5:29 PM, Robert Ramey via Boost wrote:

> On 10/18/18 2:15 PM, Stefan Seefeld via Boost wrote:
>> Hi Robert,
>>
>> On 10/18/18 4:43 PM, 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.
>>
>> [...]
>>
>> Quite a number of people (Rene, Edward, myself, ...) have argued in
>> different ways against a wholesale switch from Boost.Build to CMake.
>> While for some the point is more about incrementality of the process,
>> for others it's about autonomy and modularity.
>>
>> I'm surprised, even shocked, to see that your draft doesn't even mention
>> modularity as a goal, but again focusses exclusively on the modalities
>> of an eventual switch. I have said it often, and I'm saying it again:
>> you can't force a Boost maintainer to adopt a CMake-based build system
>> for his project. You can only show by example that it works well (by
>> picking volunteer projects as early adapters), and hope for others to
>> follow voluntarily (incrementally over the course of a couple of
>> releases), given that the maintenance burden of that new environment is
>> entirely on them.
>>
>> So, I would expect in a RFP to find requirements such as:
>>
>> * a solution must allow for a heterogeneous environment, where some
>> Boost libraries are still built with Boost.Build, while others are built
>> with CMake.
>
> I think this is a necessary conclusion given the other conditions.
> Including, but not limited to:
>
>  *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

OK, these look good, but they don't imply that a heterogeneous setup
needs to be supported. (Read: the above requirements could be met even
if all libraries were switching to CMake)

More importantly: I don't want anyone to interpret this as if a
CMake-based solution that meets the above is implicitly approved and
adopted by all maintainers. I expressly want to be able to keep using
Boost.Build (or at least, not having to use CMake :-) ), so the
requirements for heterogeneity go both ways: Boost.Build needs to become
modular in that it needs to be able to accept prerequisite projects
being built using CMake, and any CMake-based solution needs to be able
to accept prerequisites that are *not* built using CMake.

Even if these are implied in your interpretation of the above, I think
it's reasonable to spell them out explicitly.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 3:06 PM, Stefan Seefeld via Boost wrote:

>>> So, I would expect in a RFP to find requirements such as:
>>>
>>> * a solution must allow for a heterogeneous environment, where some
>>> Boost libraries are still built with Boost.Build, while others are built
>>> with CMake.
>>
>> I think this is a necessary conclusion given the other conditions.
>> Including, but not limited to:
>>
>>   *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
>
> OK, these look good, but they don't imply that a heterogeneous setup
> needs to be supported. (Read: the above requirements could be met even
> if all libraries were switching to CMake)

True - and could be met if not libraries switched to CMake.  Not that
there is not even a suggestion that boost build be replaced.  Only that
the (optionally) the user be able to build any library with CMake.  this
is all intentional.  I didn't want to impose any more than the minimal
conditions.

> More importantly: I don't want anyone to interpret this as if a
> CMake-based solution that meets the above is implicitly approved and
> adopted by all maintainers. I expressly want to be able to keep using
> Boost.Build (or at least, not having to use CMake :-) ), so the
> requirements for heterogeneity go both ways: Boost.Build needs to become
> modular in that it needs to be able to accept prerequisite projects
> being built using CMake, and any CMake-based solution needs to be able
> to accept prerequisites that are *not* built using CMake.
>
> Even if these are implied in your interpretation of the above, I think
> it's reasonable to spell them out explicitly.

OK - I'll add in a sentence to make it clearer.  Feel free to suggest
your own wording.

Robert Ramey

>
>
> Stefan
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/18/18 2:43 PM, Steven Watanabe via Boost wrote:

> AMDG
>
> On 10/18/2018 02:43 PM, Robert Ramey via Boost wrote:
>>
>> 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.
>>
>
>    I don't see how this makes sense.  For the most part,
> the code itself will be sufficient to identify the
> author (at least for those of us who have been
> following the discussions of CMake for a while).
> If the code weren't enough, the authors would give
> away their identities in the discussion
> - Either they use their real names in the discussion and
>    we can spot who is defending their own decisions or,
> - They use anonymized names which we can match with their
>    real names by their (well-known) idiosyncrasies.
> (Of course, I'm assuming that the submissions are mostly
> coming from the usual suspects.  Otherwise, we won't
> know who they are anyway, so making it anonymous is
> pointless.)
>
>> The motivation for this anonymity is to attract submitters who find the
>> boost review process distressing, annoying and/or unpleasant.
>
> This seems like a bad idea, given that we would
> expect more than a hit-and-run from the submitter.
>
>> 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.
>>
> In Christ,
> Steven Watanabe

Obviously this is a novelty in the context of Boost.  At the same time
the idea of accepting multiple submissions for the same functionality is
also a novelty for boost.  I think it is necessary in this case.  But I
was concerned about complaints that the process might not be fair.  I'm
also sensitive to complaints that Boost doesn't represent all groups
"fairly". So I thought I'd include this idea.  It's also true that it's
orthogonal to the actual substance at hand and I don't have a huge
amount of personal ego involved in this aspect. I'm happy to go along
with the consensus.  And I'd like to hear what others think.

Robert Ramey




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
AMDG

On 10/18/2018 04:19 PM, Robert Ramey via Boost wrote:
>
> Obviously this is a novelty in the context of Boost.  At the same time
> the idea of accepting multiple submissions for the same functionality is
> also a novelty for boost.

Not entirely novel.  Does anyone remember the futures review?

>  I think it is necessary in this case.  But I
> was concerned about complaints that the process might not be fair.  I'm
> also sensitive to complaints that Boost doesn't represent all groups
> "fairly". So I thought I'd include this idea.  It's also true that it's
> orthogonal to the actual substance at hand and I don't have a huge
> amount of personal ego involved in this aspect. I'm happy to go along
> with the consensus.  And I'd like to hear what others think.
>

Well, you can count me opposed.  I don't think
it adds anything other than a hassle.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:

> On 10/18/18 3:06 PM, Stefan Seefeld via Boost wrote:
>
>>>> So, I would expect in a RFP to find requirements such as:
>>>>
>>>> * a solution must allow for a heterogeneous environment, where some
>>>> Boost libraries are still built with Boost.Build, while others are
>>>> built
>>>> with CMake.
>>>
>>> I think this is a necessary conclusion given the other conditions.
>>> Including, but not limited to:
>>>
>>>   *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
>>
>> OK, these look good, but they don't imply that a heterogeneous setup
>> needs to be supported. (Read: the above requirements could be met even
>> if all libraries were switching to CMake)
>
> True - and could be met if not libraries switched to CMake.  Not that
> there is not even a suggestion that boost build be replaced.

Huh ! While what you say might be technically true, you only need to
look at the mail's subject line to get a radically different
perspective. So in a way you are contradicting yourself here: You
prepare a RFP (Request for Proposals) / Call for Submissions titled
"CMake for Boost". In the text you say you talk almost exclusively about
modularity (i.e. you tell me that the requirements could be met even
without changing the build system), but you insist that you don't want
to mention modularity because it's such a contentious topic.

Sorry, but I don't know how to parse that cleanly.

> Only that the (optionally) the user be able to build any library with
> CMake.  this is all intentional.  I didn't want to impose any more
> than the minimal conditions.

Well, that last bit requires elaboration. Are you "optionally" requiring
that a user be able to build *any* library with CMake ? How would you do
that without the library's maintainer's consent ?

Or did you mean that *some* library authors may ("optionally") switch to
CMake, without imposing any changes on anyone else ?

>
>> More importantly: I don't want anyone to interpret this as if a
>> CMake-based solution that meets the above is implicitly approved and
>> adopted by all maintainers. I expressly want to be able to keep using
>> Boost.Build (or at least, not having to use CMake :-) ), so the
>> requirements for heterogeneity go both ways: Boost.Build needs to become
>> modular in that it needs to be able to accept prerequisite projects
>> being built using CMake, and any CMake-based solution needs to be able
>> to accept prerequisites that are *not* built using CMake.
>>
>> Even if these are implied in your interpretation of the above, I think
>> it's reasonable to spell them out explicitly.
>
> OK - I'll add in a sentence to make it clearer.  Feel free to suggest
> your own wording.


My suggestion is to add a requirement that

> * a solution must allow for a heterogeneous environment, where some
> Boost libraries are still built with Boost.Build, while others are built
> with CMake.

Thanks,


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 4:05 PM, Stefan Seefeld via Boost wrote:

> On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:
>> On 10/18/18 3:06 PM, Stefan Seefeld via Boost wrote:
>>
>>>>> So, I would expect in a RFP to find requirements such as:
>>>>>
>>>>> * a solution must allow for a heterogeneous environment, where some
>>>>> Boost libraries are still built with Boost.Build, while others are
>>>>> built
>>>>> with CMake.
>>>>
>>>> I think this is a necessary conclusion given the other conditions.
>>>> Including, but not limited to:
>>>>
>>>>    *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
>>>
>>> OK, these look good, but they don't imply that a heterogeneous setup
>>> needs to be supported. (Read: the above requirements could be met even
>>> if all libraries were switching to CMake)
>>
>> True - and could be met if not libraries switched to CMake.  Not that
>> there is not even a suggestion that boost build be replaced.
>
> Huh ! While what you say might be technically true, you only need to
> look at the mail's subject line to get a radically different
> perspective. So in a way you are contradicting yourself here: You
> prepare a RFP (Request for Proposals) / Call for Submissions titled
> "CMake for Boost". In the text you say you talk almost exclusively about
> modularity (i.e. you tell me that the requirements could be met even
> without changing the build system), but you insist that you don't want
> to mention modularity because it's such a contentious topic.
>
> Sorry, but I don't know how to parse that cleanly.
>
>> Only that the (optionally) the user be able to build any library with
>> CMake.  this is all intentional.  I didn't want to impose any more
>> than the minimal conditions.
>
> Well, that last bit requires elaboration. Are you "optionally" requiring
> that a user be able to build *any* library with CMake ? How would you do
> that without the library's maintainer's consent ?
>
> Or did you mean that *some* library authors may ("optionally") switch to
> CMake, without imposing any changes on anyone else ?

I meant that a submission should provide a set of facilities for authors
and users.  Authors should be able to easily add these facilities to
their libraries and Users should be able to use these facilities to make
their usage of Boost even more pleasant than it already is.

Of course this latter would only apply to those libraries elected to
support CMake for users.  But I believe that if the submission
accomplishes it's goals (simple implementation for authors, high utility
for authors and users, etc.) it would be adopted by boost authors over a
relatively short time frame.  Of course I can't know this, but it would
be my hope.



>
>>
>>> More importantly: I don't want anyone to interpret this as if a
>>> CMake-based solution that meets the above is implicitly approved and
>>> adopted by all maintainers.
That is not my intention.

I expressly want to be able to keep using

>>> Boost.Build (or at least, not having to use CMake :-) ), so the
>>> requirements for heterogeneity go both ways: Boost.Build needs to become
>>> modular in that it needs to be able to accept prerequisite projects
>>> being built using CMake, and any CMake-based solution needs to be able
>>> to accept prerequisites that are *not* built using CMake.
>>>
>>> Even if these are implied in your interpretation of the above, I think
>>> it's reasonable to spell them out explicitly.
>>
>> OK - I'll add in a sentence to make it clearer.  Feel free to suggest
>> your own wording.
>
>
> My suggestion is to add a requirement that
>
>> * a solution must allow for a heterogeneous environment, where some
>> Boost libraries are still built with Boost.Build, while others are built
>> with CMake.

Hmmm - I intentionally avoided any explicit mention of boost build, b2,
etc. as I didn't want to foment a CMake vs Boost Build discussion which
could easily take a lot of time and be off topic.

How about, "Adding CMake support to any library shouldn't conflict with
any other facilities that Boost offers, such as Boost Build."


>
> Thanks,
>
>
> Stefan
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 7:18 PM, Robert Ramey via Boost wrote:

> On 10/18/18 4:05 PM, Stefan Seefeld via Boost wrote:
>> On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:
>>
>>> Only that the (optionally) the user be able to build any library with
>>> CMake.  this is all intentional.  I didn't want to impose any more
>>> than the minimal conditions.
>>
>> Well, that last bit requires elaboration. Are you "optionally" requiring
>> that a user be able to build *any* library with CMake ? How would you do
>> that without the library's maintainer's consent ?
>>
>> Or did you mean that *some* library authors may ("optionally") switch to
>> CMake, without imposing any changes on anyone else ?
>
> I meant that a submission should provide a set of facilities for
> authors and users.  Authors should be able to easily add these
> facilities to their libraries

But that's my point: You should not require library authors to "easily
add these facilities", as it comes with an additional maintenance
burden. It should be up to them to decide what they add.

> and Users should be able to use these facilities to make their usage
> of Boost even more pleasant than it already is.
>
> Of course this latter would only apply to those libraries elected to
> support CMake for users.  But I believe that if the submission
> accomplishes it's goals (simple implementation for authors, high
> utility for authors and users, etc.) it would be adopted by boost
> authors over a relatively short time frame.  Of course I can't know
> this, but it would be my hope.

Ah. Well, I'm certainly willing to consider any CMake-based solution,
and adopt it if I feel comfortable with it. So as long as we make it
clear that adoption is optional rather than mandatory (and that
consequently any submission needs to account for such a heterogeneous
state of affairs), we are fine. But again, that needs to be spelled out
loud and clear in the RFP.

>> My suggestion is to add a requirement that
>>
>>> * a solution must allow for a heterogeneous environment, where some
>>> Boost libraries are still built with Boost.Build, while others are
>>> built
>>> with CMake.
>
> Hmmm - I intentionally avoided any explicit mention of boost build,
> b2, etc. as I didn't want to foment a CMake vs Boost Build discussion
> which could easily take a lot of time and be off topic.

Well, there is no point not to talk about Boost.Build, as that is the
current build infrastructure. And frankly, with all the eyes on CMake
these days, you can avoid naming it as much you like, everyone sees the
elephant in the room. But most importantly: change the subject line /
the title of your Call for Submissions if you want to avoid naming the
One-Who-Must-Not-Be-Named ! :-)

>
> How about, "Adding CMake support to any library shouldn't conflict
> with any other facilities that Boost offers, such as Boost Build."

That sounds very much out of context, if it's the only mention of CMake
in the whole document. Frankly, I don't find that statement very clear,
and think that my proposed requirement above is a lot more precise and
constructive (and would remain so even if we substituted "Boost.Build"
and "CMake" by "the existing build system" and "another build system").


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 4:45 PM, Stefan Seefeld via Boost wrote:

> On 10/18/18 7:18 PM, Robert Ramey via Boost wrote:
>> On 10/18/18 4:05 PM, Stefan Seefeld via Boost wrote:
>>> On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:
>>>
>>>> Only that the (optionally) the user be able to build any library with
>>>> CMake.  this is all intentional.  I didn't want to impose any more
>>>> than the minimal conditions.
>>>
>>> Well, that last bit requires elaboration. Are you "optionally" requiring
>>> that a user be able to build *any* library with CMake ? How would you do
>>> that without the library's maintainer's consent ?
>>>
>>> Or did you mean that *some* library authors may ("optionally") switch to
>>> CMake, without imposing any changes on anyone else ?
>>
>> I meant that a submission should provide a set of facilities for
>> authors and users.  Authors should be able to easily add these
>> facilities to their libraries
>
> But that's my point: You should not require library authors to "easily
> add these facilities", as it comes with an additional maintenance
> burden. It should be up to them to decide what they add.

The language doesn't say library authors are required to add the
facilities.  It says they should be able to easily add these facilities.

What do you think it should say instead?

>> and Users should be able to use these facilities to make their usage
>> of Boost even more pleasant than it already is.
>>
>> Of course this latter would only apply to those libraries elected to
>> support CMake for users.  But I believe that if the submission
>> accomplishes it's goals (simple implementation for authors, high
>> utility for authors and users, etc.) it would be adopted by boost
>> authors over a relatively short time frame.  Of course I can't know
>> this, but it would be my hope.
>
> Ah. Well, I'm certainly willing to consider any CMake-based solution,
> and adopt it if I feel comfortable with it. So as long as we make it
> clear that adoption is optional rather than mandatory (and that
> consequently any submission needs to account for such a heterogeneous
> state of affairs), we are fine. But again, that needs to be spelled out
> loud and clear in the RFP.

OK - It seems pretty clear to me.  Feel free to suggest other language.

>
>>> My suggestion is to add a requirement that
>>>
>>>> * a solution must allow for a heterogeneous environment, where some
>>>> Boost libraries are still built with Boost.Build, while others are
>>>> built
>>>> with CMake.
>>
>> Hmmm - I intentionally avoided any explicit mention of boost build,
>> b2, etc. as I didn't want to foment a CMake vs Boost Build discussion
>> which could easily take a lot of time and be off topic.
>
> Well, there is no point not to talk about Boost.Build, as that is the
> current build infrastructure.

Right - that's why I didn't want to mention it explicitly.

> And frankly, with all the eyes on CMake
> these days, you can avoid naming it as much you like, everyone sees the
> elephant in the room.

Right - but have patience, someone will inject the topic. I've been
hoping, perhaps in vain, to avoid that.


> But most importantly: change the subject line /
> the title of your Call for Submissions if you want to avoid naming the
> One-Who-Must-Not-Be-Named ! :-)

The current title is: Call for Submissions - CMake for Boost.  I'm not
seeing where that mentions Boost Build.  I actually carefully thought
about the title just to avoid this criticism.

What do you think the title should be?

I've referred to CMake for Boost, CMake facilities for boost libraries,
etc.  Seems pretty clear to me.  But anyone who thinks this is confusing
is free to suggest a change in wording.

>> How about, "Adding CMake support to any library shouldn't conflict
>> with any other facilities that Boost offers, such as Boost Build."
>
> That sounds very much out of context, if it's the only mention of CMake
> in the whole document. Frankly, I don't find that statement very clear,
> and think that my proposed requirement above is a lot more precise and
> constructive (and would remain so even if we substituted "Boost.Build"
> and "CMake" by "the existing build system" and "another build system").

To summarize, you're in agreement with the content, we're just talking
about the phrasing to make it less subject to mis-interpretation, Right?
  I'd be happy to hear what others says about this.

I'm also interested in hearing comments about the actual substance of
the proposal.

Robert Ramey

>
> Stefan
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Oct 18, 2018 at 11:44 PM Robert Ramey via Boost
<[hidden email]> wrote:

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

A quick reply to this particular part. I'm opposed to this anonymity
protocol and think that submitters should be *required* to come
forward and actively participate in the review. I think trying to
attract more submissions by relieving the authors from the review
process is terribly misguided and detrimental to both Boost and the
proposed submissions.

Let me be very clear about this. An author of a candidate build system
solution for Boost should be willing to accept responsibility for a
core component of our infrastructure. He should be willing to become
part of the community and embrace the practices we take, including the
reviews. The author should be willing to support the use cases we have
in 100+ libraries and also provide long-term support for the solution
in the future, should it be accepted. If an author is not willing to
participate in technical discussions about his submission from the
very start then I don't want to waste my time on reviewing it, let
alone using it. If an author submits a solution with no intention to
support it then I'm not interested in it. If this means no CMake
submissions at all then so be it - I would rather have zero CMake
support in Boost than a half-baked unsupported solution.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 5:40 PM, Andrey Semashev via Boost wrote:

> A quick reply to this particular part. I'm opposed to this anonymity
> protocol and think that submitters should be *required* to come
> forward and actively participate in the review.

Of course.  But is it necessary that they identify themselves with their
real names?

> I think trying to
> attract more submissions by relieving the authors from the review
> process is terribly misguided and detrimental to both Boost and the
> proposed submissions.

In no way is it my intention to do that.  Of course I expect submitters
to participate like all authors do.

>
> Let me be very clear about this. An author of a candidate build system
> solution for Boost should be willing to accept responsibility for a
> core component of our infrastructure. He should be willing to become
> part of the community and embrace the practices we take, including the
> reviews. The author should be willing to support the use cases we have
> in 100+ libraries and also provide long-term support for the solution
> in the future, should it be accepted. If an author is not willing to
> participate in technical discussions about his submission from the
> very start then I don't want to waste my time on reviewing it, let
> alone using it. If an author submits a solution with no intention to
> support it then I'm not interested in it. If this means no CMake
> submissions at all then so be it - I would rather have zero CMake
> support in Boost than a half-baked unsupported solution.

Absolutely.

My idea was that making it more attractive for potential submitters, we
might draw more submissions than we otherwise might and hence end up
with a better one.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/18/18 5:40 PM, Andrey Semashev via Boost wrote:

> A quick reply to this particular part. I'm opposed to this anonymity
> protocol and think that submitters should be *required* to come
> forward and actively participate in the review.

Of course submitters will be required to participate. The suggestion is
that not be required to use their real names.

> I think trying to
> attract more submissions by relieving the authors from the review
> process is terribly misguided and detrimental to both Boost and the
> proposed submissions.

No one is suggesting this.

>
> Let me be very clear about this. An author of a candidate build system
> solution for Boost should be willing to accept responsibility for a
> core component of our infrastructure. He should be willing to become
> part of the community and embrace the practices we take, including the
> reviews. The author should be willing to support the use cases we have
> in 100+ libraries and also provide long-term support for the solution
> in the future, should it be accepted. If an author is not willing to
> participate in technical discussions about his submission from the
> very start then I don't want to waste my time on reviewing it, let
> alone using it. If an author submits a solution with no intention to
> support it then I'm not interested in it. If this means no CMake
> submissions at all then so be it - I would rather have zero CMake
> support in Boost than a half-baked unsupported solution.

This is all true. No one has suggested the contrary.

Robert Ramey

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 19/10/2018 13:51, Robert Ramey wrote:
> On 10/18/18 5:40 PM, Andrey Semashev wrote:
>
>> A quick reply to this particular part. I'm opposed to this anonymity
>> protocol and think that submitters should be *required* to come
>> forward and actively participate in the review.
>
> Of course.  But is it necessary that they identify themselves with their
> real names?

Is it necessary to refuse to allow them to do so?  This is how it is
presently worded.

And, if a submission is accepted, presumably anonymity would be revoked
and the submitter would face "the Boost review process" anyway, so I'm
not sure what purpose is served by trying to encourage submissions from
people who (in your own words) find that process distressing, annoying
and/or unpleasant.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 10/18/18 9:13 PM, Gavin Lambert via Boost wrote:

> On 19/10/2018 13:51, Robert Ramey wrote:
>> On 10/18/18 5:40 PM, Andrey Semashev wrote:
>>
>>> A quick reply to this particular part. I'm opposed to this anonymity
>>> protocol and think that submitters should be *required* to come
>>> forward and actively participate in the review.
>>
>> Of course.  But is it necessary that they identify themselves with
>> their real names?
>
> Is it necessary to refuse to allow them to do so?  This is how it is
> presently worded.
>
> And, if a submission is accepted, presumably anonymity would be revoked
> and the submitter would face "the Boost review process" anyway,

Hmmm - I was envisioning that only the author would be revealed after
the submission was selected via the review process.

> so I'm not sure what purpose is served by trying to encourage submissions from
> people who (in your own words) find that process distressing, annoying
> and/or unpleasant.

As I've said, I'm wondering if it might convince someone who would
otherwise not submit to submit after all.  I think there are people who
would be intimidated by the "competitive/winner take all" nature of the
process.  And I think there are others who feel that Boost is "an
insider's game" so it's not worth participating.

At the very least, I'm thinking it's something interesting to talk about
and perhaps consider.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Draft copy - Call for Submissions - CMake for Boost

Boost - Dev mailing list
On 19/10/2018 18:12, Robert Ramey wrote:
> On 10/18/18 9:13 PM, Gavin Lambert wrote:
>> And, if a submission is accepted, presumably anonymity would be
>> revoked and the submitter would face "the Boost review process" anyway,
>
> Hmmm - I was envisioning that only the author would be revealed after
> the submission was selected via the review process.

That is what I meant by "accepted".  My apologies for the poor phrasing.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12