Draft copy - Call for Submissions - CMake for Boost
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/
On Thu, Oct 18, 2018 at 3:44 PM Robert Ramey via Boost < boost@lists.boost.org> 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
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...
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
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...
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
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...
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
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...
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
On 10/18/18 8:12 PM, Robert Ramey via Boost wrote:
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.
I'm not criticizing the title. I'm pointing out the contradiction between you claiming not wanting to name CMake in the RFP, while naming it squarely in the title.
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'm asking you to add this requirement:
a solution must allow for a heterogeneous environment, where some Boost libraries are still built with Boost.Build, while others are built with CMake. or alternatively (if you are afraid of calling out the obvious):
a solution must allow for a heterogeneous environment, where some Boost libraries are still built with the existing build system, while others are built with a different one.
because that's not implied by any others. I.e. it is not merely a matter of phrasing or (mis-)interpretation. It really augments the set of requirements. Stefan -- ...ich hab' noch einen Koffer in Berlin...
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
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
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
On Thu, 18 Oct 2018, 22:44 Robert Ramey via Boost,
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, mateusz@loskot.net (Sent from mobile)
On Thu, Oct 18, 2018 at 11:44 PM Robert Ramey via Boost
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.
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
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.
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
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.
On 19/10/2018 18:12, Robert Ramey wrote:
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.
But why would those people participate, when if they do happen to win, they are then expected to face their fears? I suppose it might encourage submissions from people who have no intention of "finishing", which might in turn inspire others to use particular techniques that hadn't been originally considered. Which might be good for Boost, to get the best possible design -- but doesn't mesh well with the idea of offering a monetary incentive.
On 10/19/18 3:51 AM, Robert Ramey via Boost wrote:
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?
For the sake of mailing list and similar conversations, including the review, real names probably don't matter that much. Although, frankly, on this list there aren't many regular participants who use an alias. But there are contexts where real names are required or simply appropriate. For example, in copyright notices in the source code or documentation. Or IRL communication, should one happen e.g. in C++Now or somewhere else. There is also an awkward moment when you reveal the author's name, who was previously known by an alias, at which point you only cause confusion. And probably either you or the author has to prove his authentity.
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.
That's part of my argument - you're trying to attract submitters that would normally not want to make the submission and potentially don't want to be part of Boost. At least, that's what the document draft says. This is bad for Boost and the potential submitters.
On 10/19/18 4:45 AM, Andrey Semashev via Boost wrote:
For the sake of mailing list and similar conversations, including the review, real names probably don't matter that much. Although, frankly, on this list there aren't many regular participants who use an alias.
Boost traditionally has encouraged participants to use real names. I think this is a good thing and I think keeps discussions from going down hill - on other forums as well as boost. I was suggesting that this might be an exception to our normal policy.
But there are contexts where real names are required or simply appropriate. For example, in copyright notices in the source code or documentation. Or IRL communication, should one happen e.g. in C++Now or somewhere else.
Of course
There is also an awkward moment when you reveal the author's name, who was previously known by an alias, at which point you only cause confusion. And probably either you or the author has to prove his authentity.
Hmm - I'm not seeing this - but maybe.
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.
That's part of my argument - you're trying to attract submitters that would normally not want to make the submission and potentially don't want to be part of Boost. At least, that's what the document draft says. This is bad for Boost and the potential submitters.
So one who is uncomfortable about revealing his true identity might have difficulties when his identity is revealed in dealing with the reality that is boost. I can certainly see your point here. As I've said - it's an idea and I'm glad it's being discussed. For some time I've been concerned about the future of Boost as an organization. This is one idea - I'm curious about others. Here ate the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost outside of the development of the C++. A example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of features than it already is. It puts C++ on a slow train to oblivion. This is not usual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organization, universities - etc. All one has to do to see this is look at the papers list for the san diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. Of course the C++ committee won't address the situation. Committees don't do that. Oh - now they want to expand scope again to include tooling. Wake up and smell the coffee people. d) Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. This is the motivation behind this proposal and a number of ideas contained therein. Robert Ramey
On Fri, Oct 19, 2018 at 7:47 PM Robert Ramey via Boost
As I've said - it's an idea and I'm glad it's being discussed.
For some time I've been concerned about the future of Boost as an organization. This is one idea - I'm curious about others. Here ate the concerns I have:
Maybe this could be another thread, but I am replying here for the moment.
a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be.
I would say the same as always, no? i.e. to provide a set of useful libraries on top of C++. Now simply there are several sets depending on whether you are targeting C++03, 11, 14... However, I do see your point: many of the "killer libraries" of Boost are now part of the standard, so the value of integrating Boost for many projects is much lower (even zero or negative) than with C++03.
b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost outside of the development of the C++. A example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost.
I guess the committee is trying to adapt to modern times. Waiting for the chain Boost -> production projects -> Standard -> compiler's std lib -> production projects is way too long nowadays, compared to other languages, frameworks, etc.; specially since C++ does not have a package manager. While many projects do not need either a big standard library nor a package manager (and/or are very conservative on dependencies), it is also true that many other projects and audiences benefit from both (package manager and/or bigger standard library). Therefore, I guess the committee is trying to keep new developers learning C++ :-)
c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of features than it already is. It puts C++ on a slow train to oblivion.
Not sure. It depends on what and who you ask. For instance, I appreciate many of the additions to the standard library and the language that have been added up to C++17. However, some of the proposals (both language and library ones) could have had more time to iterate, indeed. In my view, that is fine, as long as the requirement of never deprecating/breaking old code is slightly relaxed to cope with the new speed that C++ has taken. Otherwise, as you say, we will end up in an impossible-to-disentangle mess. To be honest, I am more afraid of the compiler-side, actually. There are still many missing pieces in the major compilers, specially library-wise, which makes many features basically unusable yet if you want to remain portable. Again, the side of the chain Standard -> compiler's std lib -> production projects is way too long. Compilers are still playing catch-up with published standards, so publishing prototypes and TSs does not help as much as it could.
This is not usual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organization, universities - etc.
All one has to do to see this is look at the papers list for the san diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users.
Indeed. I only hope people do not put all the proposals in the same bag! :-( There are some proposals that I see more as "experimental" or even changing the way we write C++ (as Bjarne warns) and others that are about the "established practice". For instance (and forgive me for the "spam"), my two small proposals "std::unique_val" and "std::secure_val" are similar, yet different in that sense. std::secure_clear and std::unique_val are pretty much "established practice"; while std::secure_val can be considered "experimental" (even if researchers are working on doing compiler work on something similar). Now, when I saw the list of proposals, I felt guilty for sending my two small ones adding to the noise; but really, I do believe adding such simple kind of stuff is a plus for C++ users. The ranges proposal, that is a bit not-too-simple for my taste, but...
Of course the C++ committee won't address the situation. Committees don't do that. Oh - now they want to expand scope again to include tooling. Wake up and smell the coffee people.
d) Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
I am not sure I follow from c) to d). In other words, while the committee may not be addressing the situation (I don't know), I am not sure how Boost solves that, specially since most of the risky/controversial proposals are the language feature ones, which Boost cannot (typically) provide establish practice for. What do you mean? Cheers, Miguel
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
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
AMDG On 10/23/2018 03:35 PM, Raffi Enficiaud via Boost wrote:
<snip> 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?
Yes. They're pretty rare, though. https://github.com/boostorg/type_index/blob/develop/test/Jamfile.v2#L59 In Christ, Steven Watanabe
On 10/23/18 2:35 PM, Raffi Enficiaud via Boost wrote:
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?
Not yet. Most of the comments so far have been about wording and not enough to generate a new version.
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?
I titled it "Facilities and features" below. I see now that this was confusing. Sorry about that.
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.
I think it's going to be significantly more than that. CMake documentation is not a great model. I see the new book: Professional CMake: A Practical Guide Version: 1.0.3 © 2018 by Craig Scott as a model. It's 420 pages long. I would like to see manual in this style for Boost CMake. Of course it would be much, much smaller. It would be more "cookbook" style. Of course I believe in testing. And such a manual is easy to test. At the next CPPCon round up some volunteers and challange them to implement CMake for a given library. It should take under an hour. If it doesn't, the test failed.
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.
Right. Once you've automagically built the libraries using b2, then normally one just uses his build system to incorporate the prebuilt libraries into his app. If b2 is being used to build the app, then the incorporation of a library into one's app can be very smooth. But b2 isn't widely used outside of the building and testing of boost libraries - as far as I know.
CMake contains already the FindBoost module:
I've tried this but it didn't go smoothly for me. I forget why.
- Is the intent here to be able to replace CMake's FindBoost it with our own?
I believe that CMake for boost would create FindPackage for each boost library.
- Should that be on a freshly cloned repository without prior build step?
I've left the requirements pretty open. In the minimum, it would just rely on libraries built by b2. In the max, it might build the boost libraries to be used. Note that in some cases, users incorporate the source of the libraries into their app, so presumably that might be supported as well. I've specified "scope" in such a way that a submitter can make his submission cover those things that CMake can really help. I don't want someone to create a version of b2 made by CMake. I'm suggesting that CMake support those things that CMake is really built or and leave the things it can't to some other tool. I seek improvement of our current system - I'm not demanding perfection or realization of some build paradise.
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.
A submitter might propose that. By my perusal of CMake books and documentation leads me to be surprised were FindBoost would be suggest. Of course when submissions are opened for review, you'll have plenty of opportunity to spitball.
Also, there are different ways of incorporating. I am pretty sure that there are very conflicting opinions on this.
Right - that's what the review is for.
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
it will have to be determined somehow. How exactly this is to be done or not done would be part of the submission. It's my intent not to overspecify this.
Facilities and features Scope? -----------------------
*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"?
I'm thinking something like FindBoost, FindPackage, or ... ?
Should that cover all the possible use cases that currently b2 offers?
Not a requirement. It doesn't have to replace b2. It just has to be something that lots of users would find helpful.
*3) link only tests - must pass/ must fail
Do we have link only tests in b2? Can somebody point me to an example?
I believe we do but I'd have to search for an example which I'm disinclined to so right now.
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.
Hmmm - not necessarily. But yeah. Boost does depend on other tools like xslt. But I'm thinking requiring python would be too much. Of course the extra burden of other tools would be something to be evaluated during the review of the submissions.
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.
Hmmm - I had just assumed that CMake with boost would require CMakeLists.txt and that this would include dependencies. But maybe not. I would like to leave the option of manual specification of dependencies to the library author. That is my intent here. If this is a rash assumption I suppose I could remove the explicit mention of CMakeLists.txt here without changing the intent.
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)).
Note that being able to use CMake to build boost libraries is not an explicit requirement. It would be nice, but the most important goal is to support users who CMake to build their own app to incorporate boost into their projects. So.... I'm reluctant to specify requirements which apply to building boost itself. If someone's submission includes the facility to build (or recurrsively build) boost libraries and it really works well, that would be great though. Also I'd be happy to consider a submission which fulfills the minimum requirements but leaves the door open to added functionality in the future.
*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.)
Currently using b2, the build system discerns much of the information needs by looking in the direction structure outside the the library itself. This means if you move just the library somewhere else, the library/tests can't be built. This feature may make sense for b2 - but I see it a very bad idea in this context. using, building, testing, etc. of a library should not depend on things outside the library. (other than tools of course).
*2) building out of tree Is this relevant?
To me this is a very important requirement. Currently with b2, running tests, building or whatever changes the directory structure. This creates a whole lot of problems. Not the least of which if you run the same command twice, you might not get the same results. This is probably not a real issue as CMake supports and promotes out of tree builds as a fundamental feature.
*3) no need for installing libraries not used by the build target
Do you mean "... build targets and any of its dependencies"?
LOL - I wanted to avoid the word dependencies so I phrased it this way.
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?
Right. These requirements ARE loose. That is, some things are really required, somethings are "nice to have" etc. This gives submitters lots of leeway to include "cool features" which are easy to include and to exclude "nasty implementations" which are not strictly required. I have no idea how many submissions I might receive - honestly NO idea. It could well be zero - not a surprise and probably a relief. It could be 20. I've planned on to a pre-review to verify that submissions actually fulfill the requirements listed here. For example, if someone submits a proposal without documentation, I can easily just reject it for not meeting the rules. Same if it fails to meet necessary requirements - those marked with a *, they can be rejected immediatly as well. If it's very clearly not a serious submission, I would feel justified in rejecting that as well. Review is serious work, I'm not go to ask people waste their time. Of course some people will be upset about getting summarily rejected. But it's unavoidable. Just for fun here is my guess: 10 submissions received 5 rejected for have no or almost no documentation 2 rejected for just being ridiculous 2 seriously reviewed.
c) The name of the author of a submission will not be included in the
...
a tangible token of our gratitude for solving one of Boosts most pressing and difficult problem 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
But we hope that it will serve as the limit of toxic for boost.
The anonymity has been question. It's pretty novel. I really don't know how it would turn out. But remember that this whole idea is novel for boost. It's sort of like the XPrize for C++. Note anonymity is not without precedent. Submissions to scientific journals are reviewed by reviewers who don't know who the submitters are. So the idea is not totally off the wall. And I sincerely worry that the boost review process can be so toxic that it my dissuade potential submitters. This goes double given that we're hosting a "contest". Suppose we were hosting a "context" for a new library X. You start working on your submission. Just as your about to submit it, it's announced that a submission from Howard Hinnant has just been received. Hmmm how would you feel about submitting now? Another thing is that boost will soon be criticized (if it hasn't already) for being an exclusionary, elitist, faux meritocracy. I'm thinking of stepping up and confronting this head-on by reinforcing the fact that boost IS a meritocracy, proud of it, and willing to prove it. I concede I'm sort of enamored with the idea. But I will that's it pretty radical for a 20 year old organization mostly run by really old people.
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?
So far this is the only complete proposal. We've been asking for this for 10 years. This is the third attempt. If you've got a better idea, now is the time to propose it.
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.
LOL - no I'm not. This is a sufficiently novel idea that the odds of success can't be rated at more than 50%. If it fails, that'll be the third time. There will be an opportunity for a fourth attempt. If no acceptable submissions are received or the review process deems none acceptable, the we're back to where we started - no harm no foul.
So nothing for collaboration, and nothing for incremental support of cmake.
I'm not sure I get this. Boost is all about collaboration. I'm trying to apply what we've learned about promoting the development of quality libraries to the development of quality tools.
How can we fix that? I would love to collaborate openly on this.
a) craft you're own submission. b) participate in the review process c) add your own PR to the github for the tool d) offer friendly constructive advice to the author/maintainer of the Boost CMake facility. Robert Ramey
Raffi
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Oct 18, 2018 at 4:44 PM Robert Ramey via Boost < boost@lists.boost.org> 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.
Thank you Robert! It is awesome to see this effort move forward. Overall I think the proposal is sound. There were a couple parts that I think could be improved to get a stronger consensus on the call itself. c) The name of the author of a submission will not be included in the
submission. [...]
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.
Have you identified any folks in particular who would like to submit a proposal but only under the condition of anonymity? Like others, I'd suggest snipping this part. If someone would like to come forward with a proposal anonymously, I think we should do our best to accommodate, but beyond that I don't think it should be a requirement. I don't think anonymity will significantly impact the number of proposals coming forward or the discussion, and it looks strange for a Boost call. 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.
I'm not sure how or if this can be done, but I can certainly reach out to the conservancy to get some advice. I think this is an interesting idea, but one drawback is that it creates a disincentive for collaboration which should be encouraged. Perhaps it could be worded in a way such that the award can be given to those who provided outstanding contributions towards the effort. For example, it could partially go toward the winning author, a solid runner up, or perhaps someone else who contributed in a significant way. A plaque awarded at C++Now is another option. -- David
participants (10)
-
Andrey Semashev -
David Sankel -
Gavin Lambert -
Mateusz Loskot -
Miguel Ojeda -
Raffi Enficiaud -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Steven Watanabe