On May 16, 2016, at 8:31 AM, Robert Ramey wrote:

On 5/15/16 8:32 PM, David Sankel wrote:

...

We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory.

Hmmm - as far as I understand it, any policy has been a requirement that libraries include build, src, doc and test directories and that that these include boost build scripts. I don't think that "policy" has ever prohibited including anything else at the author's discretion. The serialization library has a number of "extra" top level directories: test_util, performance, cmake. A number of libraries have stuff in the doc directory which is special. It doesn't have a top level cmake file because I chose not to do this, not because I thought it violated some "policy". I've been doing this for many years.

Yes, but there have been a few who have mentioned that it does break the guidelines. So lets fix the guidelines to avoid future confusion about this.

So I don't there's a lot to discuss.

Though it's off topic - CMake isn't all that much better than boost build - actually it's not even comparable as it doesn't do the the same thing.

Robert Ramey

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

As a complete neutral here, I think that Michal is very much on-point. I've been a C++ programmer for 20+ years, and have used boost on-and-off for much of that time. For much of my professional career I have been working with build systems and configuration management, and I know much more about C++ build systems than a person who wishes to remain sane should know :-) I've used make, autotools, MSBuild, CMake, jam, scons, Premake, and more. CMake has "won". It isn't perfect, but it's the utterly dominant defacto standard. Unless there is an amazingly compelling reason not to migrate, putting together a CMake migration plan makes good sense. And the same kind of thinking should be applied to issue tracking, version control, automation, etc, IMHO. It is only through my involvement with Ethereum that I am now more closely looking at Boost as a DEVELOPER rather than as a USER, and it looks awfully old-fashioned and stick-in-mud to me, I have to say, sadly. Anyway - enough from me ... best wishes to you all. You have a gem with your codebase. Please don't let it wither on the vine ... On Mon, May 16, 2016 at 9:32 AM, Michał Dominiak wrote:

Hi,

The thing is, despite whether you believe bjam is better than CMake or not (please tell me how I can easily build Boost.MPI with Bjam without an additional config file that allows me to *just* do that?), there's another very important aspect of the problem, and it's whether Boost will survive in the current C++ world, where everyone uses CMake. People writing code to build independent parts of Boost for static linking in their libraries or tools that are supposed to be portable, regardless of the target or build OS, are already building it with CMake... probably because everything else in the world is built with CMake (or with autofo-- autotools, but that's easy enough to wrap with ExternalProject - for the record, I'm not saying that it's good). An example from the top of my head: YCM.

This isn't really a discussion that needs to go deeply technical, but if you want to do that, by all means, please do point out what bjam does better than CMake - as in, please make a list of stuff that is so great in bjam, so that we can actually discuss this technically (just mentioning usage-requirements doesn't do this for me, because if I understand the docs correctly, it's trivial to do this in CMake). For the record: I work with CMake on a daily basis at work, and I feel deep hatred for some of its idiosyncrasies, but I like it far better than working with bjam (and trust me, I've build my fair share of different Boost configurations over the past few years).

Now; we could make a poll to see whether the distribution of people for CMake among all Boost members is the same as it was at the panel at C++Now (where the vast majority of people raised their hands after the SC asked who wants Boost to be converted to CMake - or thinks it *needs* to be converted), but I don't know if going there is productive; what Dave and David said about the future and the deep need to actually make a move there and not get eaten by everybody who does that is probably the primary argument for actually doing the switch here.

I realize I am kinda derailing this thread, and there's a chance this should be made into a separate one; that might actually be a good idea. Just let me say one more thing.

I spoke with a few (as in: not so many of them; I wish I thought about this earlier than Saturday) at C++Now, including Dave, and asked them whether they think that the glue between different Boost libraries, that is: the build system used for the entire thing - should be considered a part of each individual library, or as something that is outside of the scope for each individual library, and rather a part of Boost itself, which would 1) make the authors of each library not actually own their build systems, just the code (which I believe is a good thing) and 2) make the Steering Committee the de facto owner of the build system *across Boost*, which, in turn, would allow them to make a decision saying "we are going to switch to CMake over the next X years/releases/whatever, and here's how we are doing it".

I believe that (2) should be done; if we just *encourage* library authors to also support CMake in their libraries, it will result with a lot of build systems that are separate entities, when I believe that they should be standardized across Boost - and this is the part when I don't believe that without the SC's definitive and authoritative voice saying "this is how it's done", it won't be done in a way that could potentially be made official, because of the differences different people have about build systems.

In the end, this is about moving forward, instead of staying in the same place forever, because as in many different industries, in this one not moving actually means moving backwards, and moving backwards is the kind of a thing that can murder Boost.

I expect people to raise opinions of "this is too radical" and "why should we listen to somebody posting on these mailing lists for the first time with a message like this one?"; that is fine. But the primary goal I have here is to remind you again (or tell you, if you weren't there) what Dave said on Saturday: the Steering Committee's role is to protect Boost. I believe that not moving forwards with an actual, active (as opposed to passive "yeah, you can do this; whatever") switch to CMake (*even despite any actual technical argument proving Bjam's superiority!*) is actively harmful in the era where almost all relevant (this includes proprietary!), big C++ projects that are not GNU are using CMake to build themselves.

A final note, again kind of repeating what Dave said (because I think it's extremely important and we tend to forget it these days): Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*.

Thanks in advance for no open hostility in replies to this, hopefully we can make some progress thanks to Saturday's discussion that basically sparked this email.

On Mon, May 16, 2016 at 5:48 PM Mikhail Strelnikov < mikhail.strelnikov@gmail.com> wrote:

...

...

* Several libraries, such as Boost.Hana and Boost.Spirit, have two distribution mechanisms: one as distributed with Boost and the other as

an

...

independent package.

What if header-only library A is using Hana from Boost 1.61 and header-only library B is using independent Hana released in 2017? Will this violate ODR (if compile at all) if both A and B are used in the same application?

...

The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution.

Hana does already include CMakeLists.txt in 1.61, why is that?

Why header-only library such as Hana needs a build script that is 5 pages long (plus walls of text in cmake directory)? Bjam does support header-only libraries and does not require much from library author.

If you have 1.61 extracted, navigate to boost/libs/hana/CMakeLists.txt line 105 and please tell me why library included in Boost 1.61 is trying to search for Boost 1.59? Do you want every Boost library to search their own version of Boost?

It requires CMake 3.0 released in 2014 and searches for Boost 1.59 released in 2015 - this is not going to work. Best FindBoost.cmake has to offer is 1.56.

What BOOST_HANA_HAS_WEXTRA does?

What is boost/libs/hana/LICENSE.md doing? Is this legal?

* Several companies have revealed that they are building Boost with

...

their own custom CMake scripts. The suggested policy change would enable authors to relieve the infrastructure cost of their CMake users and unify how their library is built.

I have opposite experience by replacing dozens of CMake scripts with one tiny Jamfile.

...

* CMake is, by far, the most popular build system for C++. Allowing authors to support CMake users in addition to BJam will help the Boost ecosystem to grow and thrive by lowering the barriers to access.

IMHO, CMakeLists.txt looks ugly as everything in camel starting with C. There are lots of Boost libraries having only "index.html" in their top-level directory, look, there is a pattern here and I'm not sure this should be uglified.

I don't care too much about popularity, but Bjam/BB does support C++ much better than CMake. It has, for example, "usage-requirements".

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

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

-- bob@summerwill.net

I think Bob has captured my feelings on this very well. In particular: On Mon, May 16, 2016 at 10:38 AM, Bob Summerwill wrote:

CMake has "won". It isn't perfect, but it's the utterly dominant defacto standard. Unless there is an amazingly compelling reason not to migrate, putting together a CMake migration plan makes good sense.

I don't know Boost Build very well (I'm trying to learn more), but it seems like a perfectly fine build system. I wouldn't be surprised to discover that it's superior to CMake, since I'm very aware of that tool's many flaws. However, CMake is *good enough*, and far, far more popular than bjam. In fact, I believe Boost itself is the only bjam project I've ever used. To someone who comes from other open source projects, it creates a barrier to adoption and also bolsters the image of Boost as arcane and hard to understand. And the same kind of thinking should be applied to issue tracking, version

control, automation, etc, IMHO.

Ditto. In the web development world, the popularity of some default choices for each infrastructure element makes it fast to get new developers up to speed and makes a project look "friendly". If we want to attract more users and developers, we should do the same. Jeff

Hi Alain,

On May 16, 2016, at 1:16 PM, alainm wrote:

I dropped trying to contribute, I cannot waste days trying to understand how bjam tries to work *just for a single project*. Same thing goes for the doc BTW.

That’s too bad, we could use your help. As far as why Intel MPI isn’t natively supported by Boost tools without explicit configuration, it’s complicated. For starters, iMPI doesn’t seem to report the compiler return code back through their mpicxx wrapper script so, for example, if we pass an invalid option to the Intel Mpi wrapper, we get back a zero return code (which we assume means the option is supported by the wrapper / compiler). -bash-4.1$ mpicxx -showme:compile icpc: command line warning #10006: ignoring unknown option '-showme:compile' /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' -bash-4.1$ echo $? 0 While if we pass this same option directly to the compiler, we get a failure rc. -bash-4.1$ icpc -showme:compile icpc: command line warning #10006: ignoring unknown option '-showme:compile' icpc: command line error: no files specified; for help type "icpc -help" -bash-4.1$ echo $? 1 This makes it nearly impossible for us to automatically detect the Intel MPI wrapper in bb if we can’t interrogate the wrapper to find out what’s supported. If you have an Intel MPI contact, perhaps you could raise this issue with them or have them contact me and we’ll work this out together. Noel

On 5/17/2016 10:24 AM, Niall Douglas wrote:

On 16 May 2016 at 16:32, Michał Dominiak wrote:

...

A final note, again kind of repeating what Dave said (because I think it's extremely important and we tend to forget it these days): Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*.

I wanted to repost tagging the Subject field to emphasise this exact sentiment which might have been missed (by Dave I assume you mean Dave Abrahams, it sounds like him anyway). I'd personally consider this paragraph the most important thing in your post and it sums up my personal position *exactly*.

The usual response is anyone proposing disruptive change to Boost is "somebody has to lead this out" or "Boost is community led" i.e. build consensus first. Both those responses do not allow for the highly disruptive clean fork of Boost necessary to return Boost to serving C++ at large, rather than the never ending Boost navel gazing it has become. Such a move can only be generated by non-passive leadership, and Boost doesn't have active leadership.

But I'll freely admit I have given up on trying to make any substantial changes to Boost. I prototyped as I said I would a Boost-lite transition layer suitable for a clean Boost fork which I'm using in all my own code. Nobody was interested.

Maybe no one was interested because no one knows what you are talking about.

The community *likes* things just the way they are: serving the Boost community, and to hell with the entire C++ community. A shame, and a waste, and I suspect in the long term self defeating.

Boost consists of about 130 different libraries. I venture to guess that there is not a single library author of those 130 different libraries that wouldn't like to see his library used more by the C++ community. But why you think that Boost library authors write only for other Boost library authors rather than for any C++ programmer is something you need to explain in specific terms. Just making that claim does not explain anything.

On 5/19/2016 5:17 AM, Niall Douglas wrote:

On 17 May 2016 at 19:39, Edward Diener wrote:

...

...

But I'll freely admit I have given up on trying to make any substantial changes to Boost. I prototyped as I said I would a Boost-lite transition layer suitable for a clean Boost fork which I'm using in all my own code. Nobody was interested.

Maybe no one was interested because no one knows what you are talking about.

This I think is inaccurate except maybe for your good self personally.

I presented a plan for how to technically transition to a C++ 14 only Boost 2.0 at my C++ Now 2015 presentation:

https://goo.gl/VFFXUl

The talk was well attended, and by much of the more senior Boost community members.

I got the impression everyone understood well what was being proposed. Understanding was not the issue. Agreement with forking Boost into a C++ 14 only edition was the issue.

OK, I wasn't at C++ Now 2015.

...

...

The community *likes* things just the way they are: serving the Boost community, and to hell with the entire C++ community. A shame, and a waste, and I suspect in the long term self defeating.

Boost consists of about 130 different libraries. I venture to guess that there is not a single library author of those 130 different libraries that wouldn't like to see his library used more by the C++ community. But why you think that Boost library authors write only for other Boost library authors rather than for any C++ programmer is something you need to explain in specific terms. Just making that claim does not explain anything.

The C++ 14 only libraries contributed to date are clearly written first for C++ not Boost.

What do you mean that a library is "written first for Boost" ?

They are the future we should be proactively encouraging into a new clean ground up redesigned fork of Boost, a Boost 2.0, instead of corralling them into legacy and outdated packaging, build, design, documentation and idioms

What is outdated about the "packaging, build, design, documentation, and idioms of current Boost" ?

out of some misguided desire for serving the legacy Boost usership before that of the wider C++ community.

This is just more rhetoric without any basis in fact. People who write libraries for Boost inevitably write them to be useful for C++ programmers. In a wide variety of libraries some will be more or less useful for varying levels of C++ programming. You are on some sort of crusade sir in order to push forward your opinion that only libraries which use the latest C++ standard are useful for C++ programmers. I find very little technical basis for such an opinion. I do agree that libraries written using the latest C++ standard can offer some language facilities for easier use than otherwise. But believing that libraries not using the latest C++ standard are not worthwhile is just silly.

On 19 May 2016, at 17:36, Robert Ramey wrote:

Boost as from day one had the policy that any library submitted should be compatible with the latest C++ standard. Any library author is free to build his library with C++14 only.

This is why I think the monolithic release is no longer a good format, most is not a coherent set of libraries that are all usable from a single users perspective and most users only need a couple libraries. Various attempts have been proposed to reduce dependencies inside boost with the aim to make libraries separately downloadable/releasable. Moving to git was a big change, but in general it’s very difficult to get consensus on *any* change for the better (for some at least). Why is it so difficult to introduce any change? Can’t we give library maintainers some parallel optionalities and see what will evolve out of it -or not-: allow to formally support aditional build systems, other documentation systems, allow different types of release schedules: standalone and separately downloadable headers only libraries that have zero dependencies.

On 19 May 2016, at 18:07, Rene Rivera wrote:

On Thu, May 19, 2016 at 11:01 AM, M.A. van den Berg wrote:

...

allow to formally support aditional build systems,

We already allow that.

...

other documentation systems,

We already allow that.

...

allow different types of release schedules:

We already allow that.

...

standalone and separately downloadable headers only libraries that have zero dependencies.

We already allow that.

And not only that.. We already have libraries that do one to all of the above.

As you might expect I’m very interested. Can you give more info about this? I think these are major elements that drive the interest to contribute and it’s not clear. E.g. I can’t find any statements about this in e.g. the “Boost Library Submission Process” to name something. More visibility to this would IMO add value.

On 19 May 2016, at 18:15, Vinnie Falco wrote:

On Thu, May 19, 2016 at 12:01 PM, M.A. van den Berg wrote:

...

This is why I think the monolithic release is no longer a good format, most is not a coherent set of libraries that are all usable from a single users perspective and most users only need a couple libraries. Various attempts have been proposed to reduce dependencies inside boost with the aim to make libraries separately downloadable/releasable.

I like the monolithic format. Its easy to get boost onto a system ("sudo apt-get boost" or whatever). And once its there, you have confidence that you get the whole toolbox should you need it. Its very convenient when building an application or a library to be able to grab any part of boost you need and just use it. Once you accept boost as a dependency then you know anyone using your application or library will have it available and it broadens the parts you can use.

Even if you only need one part of boost (e.g., asio) what's the big deal about installing the whole thing? Its just as easy to install all of boost as it is to install a single library. Some might object that this is not a sustainable development model and if there were a thousand other libraries similar to Boost in that they each aggregated a hundred or more individual libraries into one package then I might agree.

But the reality is that there is only one boost. Nothing else even comes in second place. Having a boost dependency as a single monolithic package with more libraries than you might need at the moment is a reasonable solution, and one that does not waste 180+ project managers time with trying to make their library compile without the rest of boost.

I also like “sudo apt-get”, and I also like the it pulls in all the things you need and not having to worry about things, that’s exactly what I would love to see. The Debian package manager however does not download the whole repository of all debian packages, instead it models package dependencies and download the dependency tree. For boost this would mean that I could run “sudo apt-get boost-math” that it would download boost-math, boost core and maybe a couple more dependencies. I would also be able to pin version "sudo apt-get boost-math-1.31"

On 19.05.2016 18:13, Daniel James wrote:

On 19 May 2016 at 17:25, M.A. van den Berg wrote:

...

I also like “sudo apt-get”, and I also like the it pulls in all the things you need and not having to worry about things, that’s exactly what I would love to see.

The Debian package manager however does not download the whole repository of all debian packages, instead it models package dependencies and download the dependency tree. Debian's great. As far as I know, it's the only modularization of boost in use, and it's been working well for years, so I think it'd be a good model for us to base our efforts on. I suspect having a smaller number of modules helps usability as well.

Fedora has been doing the same for many years. In fact, I'm not aware of any Linux distro that doesn't ship individual Boost libraries, which is why I have been promoting to do this modularization "inhouse", to avoid to put that burden on package maintainers, and different distros to vary slightly in their way to implement this, causing headaches for users on those platforms. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 20 May 2016 at 07:35, Vladimir Prus wrote:

I think the reference to modularization in Debian is slightly misleading. Each component with separately compiled libraries become a separate package. The header-only libraries are all inside a single package, libboost-dev or something like that. It's not like you can separately install boost.any

It really doesn't matter if you can separately install boost.any or not. Most of the pain comes from binaries - especially for people who don't really care or want to know about boost. Downloading some headers and adding to the include path is easy enough for a developer, and unnecessary for a user, who only needs the binaries.

On 19 May 2016 at 23:35, Stefan Seefeld wrote:

Fedora has been doing the same for many years. In fact, I'm not aware of any Linux distro that doesn't ship individual Boost libraries, which is why I have been promoting to do this modularization "inhouse", to avoid to put that burden on package maintainers, and different distros to vary slightly in their way to implement this, causing headaches for users on those platforms.

OK, so any ideas how to do that? I assume they don't need separate tarballs, so maybe just some description of how to build libraries, which binaries require other binaries, and which files go into which package?

I rarely contribute anything to boost, unfortunately, but maybe you might find my input on this topic worth considering. RE: Monolithic boost... This has worked okay for me. For a new boost release, I download the monolith, compile according to our standards, and make that release available to others on my team for integration with the rest of the product. I try to keep it up to date, to resolve any possible bugs, get new features, etc. RE: C++14 adherence... We have a peculiar problem here. We need to be able to compile our code on compilers that are about 10 years old. I want to use the spiffy-great features of the latest compiler specifications, but can't due to this constraint. Insisting that we can use a newer compiler won't work; our customers specifically use old operating systems because they have security flaws about which they wish to teach, hence why our software must work on older OSes, and why we have to support older compilers (the ones that were available on these OSes). I've already tried compiling newer versions of g++ on some of these with varying degrees of success. So, at least to our use case, we hold as valuable the idea that at least some parts of boost not progress to exclude old compilers. We need that support. If one makes a separate distribution that only provides C++14 support, that's fine, but any idea that involves dropping support for older compilers altogether would require we stick to older versions of the boost distribution. That may limit the degree to which we will benefit from the collection, or any improvements made to it. RE: Dependencies... I once thought it might be valuable to ascertain which libraries I use, pull those bits out, and set up a reduced subset of the boost collection to just what we actually use in our product to help reduce how much of the collection we compile, etc. It's fantastically difficult to achieve, and in the end, I don't think it is worthwhile. By doing so, I would discourage the exploration of other parts of the library my team might find useful. Consequently, I don't bother. I just make the whole thing available to the team, and let them choose what they wish to use, absent the bits that we simply cannot use due to our requirement that we have to compile on ridiculously old compilers. I hope this information on how one small team of developers use this tool is useful to you. I'd be happy to answer any questions, if you'd like, on our use of boost if it would help guide your collective efforts. - Trey

On Fri, May 20, 2016 at 10:52 AM Robert Ramey wrote:

On 5/20/16 2:32 AM, Joseph Van Riper wrote:

...

I hope this information on how one small team of developers use this tool is useful to you. I'd be happy to answer any questions, if you'd like, on our use of boost if it would help guide your collective efforts.

I liked your post. It's easy for us to spend too much time arguing about what "real users" have to do and what our real constraints are.

Heh, I've lurked for a while now, to get a feel for the community. I know we use boost in ways that are a little different than, say, a games developer, but I suppose if nobody says anything, you won't know how anyone uses boost, which leaves you with nothing but theoretical arguments of imaginary stakeholders.

Since your company needs to make the effort to keep things up to date and certify the latest version for your environment anyway, consider becoming a boost tester. It's a mostly automatic process which does most or all of what you're doing and it would be very helpful for the rest of us.

Hmm... that is not a bad idea, and would at least be one small thing we could do to help. Our build of boost is slightly unique, in that we must build on Linux with -fPIC, static libraries binding to static runtime libraries (I can almost see some people rolling eyes and shaking heads, but this decision came after quite a lot of thought and consideration for our peculiar needs), so if that kind of information is useful, all the better. I've already automated boost updates on the Linux machines we support (Debian build machines dating back to Squeeze, although I probably need to make older machines). I don't think anyone would complain if I set up an automated way to pull down release candidates or the like for automated testing, provided this didn't get in the way for our own efforts (e.g. constant, 24-hour-a-day endless testing). I will look into that. - Trey

Am 20.05.2016 um 11:32 schrieb Joseph Van Riper:

RE: Monolithic boost...

This has worked okay for me. For a new boost release, I download the monolith, compile according to our standards, and make that release available to others on my team for integration with the rest of the product. I try to keep it up to date, to resolve any possible bugs, get new features, etc.

This is exactly my modus operandi and matches my experiences: get the whole thing, clean it up, compile it, distribute it, and use it. It's as easy as that. One exception: I build it from branches forked off from the official git tags.

RE: Dependencies...

In our build system (using MSBuild) taking a dependency on a particular version of Boost takes no more than telling the version number of choice. Want 1.5.7? Bam, here you get it. Want another one? Wait a second - pleased to serve you. My colleagues want it as easy as possible, fiddling with individual versions of every single library in Boost that they might consume is no option. Simplicity and tested interoperability wins hands down. Exploring another Boost.xyz library is much easier if it is just there, tested and ready for consumption. Just another sampling point of real life usage in our company in the past seven years. Ciao Dani

On 19 May 2016 at 8:36, Robert Ramey wrote:

Given the above, I never understood what you're proposal was (actually is, because I still don't understand it).

Simplified: 1. New Boost 2.0 distribution with rebooted internals incompatible with Boost 1.x. C++ 14 STL used by default. 2. Rebooted internals designed by a committee of the willing and with a yay/nay vote of the usership of the final design. No arguments with the plan from outside the committee, just yay/nay. Niall's personal top ten ideas for rebooted internals (committee decides after investigation of everyone's proposed options): 1. cmake build system throughout. 2. ctest test system throughout. 3. cdash reporting system throughout. 4. Niall's Boost 1.x compatibility shim layer (which he presented at C++ Now 2015) allowing a single source code base to be part of Boost 1.x and 2.x simultaneously. Library maintainers decide to opt into the shim, or not. (4a. Even if not using compatibility shim, all Boost 2.0 libraries version their ABI and API. Some libraries may optionally enforce ABI compliance using that tool) 5. New documentation system based on doxygen comments somehow. 6. New online single header generation facility so you tick the Boost 2.0 libraries you want and it spits out a single drop in header file. 7. Built in edge execution coverage testing and fuzz testing using Niall's fancy new LLVM based automated kernel test infrastructure he's currently working on for presentation in 2017 (it's not written yet, but looking seriously cool). 8. clang AST based enforcement of Boost coding guidelines. 9. All Boost 2.x libraries to be C++ Modules 10. There is no longer any Boost 2.x distribution as a ZIP archive. Instead all contributors to Boost 2.x libraries are required to use cryptographically signed git commits and tags. We push distribution onto the online distro generator and onto github and dispense with official releases entirely in favour of cryptographically signed tags meaning "this is known to work well" as defined by Travis + Appveyor running a deep suite of unit, integration and functional tests. I have more items if I were to trawl my notes. Those just came to the top of my head. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 20.05.2016 11:12, Robert Ramey wrote:

On 5/20/16 5:25 AM, Niall Douglas wrote:

Thanks for a good summary.

I <sniped> the whole thing in the interest of brevity. I don't intend to address the specifics of the proposal here. It would be too long and way too off topic. But I do have a couple of observations.

a) It's breathtaking in it's scope. You can't be accused of being timid. Feel free to take that as a compliment.

b) There is no way Boost could get to this place starting from where we are now by means of evolution. The gap is just too broad. You'll have to think in terms of intelligent design rather than evolution. This has been done before - after all boost itself was founded by a small group of people who decided to strike out on a whole new path.

This topic is coming up every couple of years, and sadly enough the discussion eventually ends in exactly the same way, simply by running out of steam. I agree that the proposal as it is put forward is quite unrealistic. I also think it's ill-conceived, precisely because it requires top-down design rather than allowing for evolution. And at the scale of the current Boost organization I think there just is no way to do top-down design. So my counter-proposal (which I have repeatedly voiced over past years) would be to let Boost evolve into an *umbrella organization* with a relatively high degree of autonomy for *member projects* to decide for their own on things like what infrastructure tools to use (to build, test, document, to track issues and feature requests, etc.), so long as certain quality standards are maintained. It is absurd how much ink is wasted on completely meaningless questions such as where build system artifacts should be placed, as those have absolutely no impact on end-users (and in fact don't even benefit boost developers, as most of the time these discussions just fade away without any conclusions, or even actions). So the only way to become more efficient is to scale down the scope of such discussions to individual projects and their communities. At least I don't have any time to meaningfully participate in such discussions, and so I put my focus on maintaining Boost.Python as independently as possible, simply as a matter of efficiency. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 20.05.2016 11:55, Peter Dimov wrote:

Stefan Seefeld wrote:

...

So my counter-proposal (which I have repeatedly voiced over past years) would be to let Boost evolve into an *umbrella organization* with a relatively high degree of autonomy for *member projects* to decide for their own on things like what infrastructure tools to use (to build, test, document, to track issues and feature requests, etc.), so long as certain quality standards are maintained.

And what will this umbrella organization actually *do*?

* provide general guidelines (just as now, but relaxed) * provide infrastructure * provide administrative, financial, and perhaps legal support * do reviews to accept new member projects Please note that there is one important condition that such independence would build upon: A discipline of ABI- and API-compatibility between releases, that allows downstream project B to depend on upstream project A while keeping its own release cycle. Note that, while likely being the most difficult aspect of this proposal, it's something that we have been discussing for a long time, and which would be good engineering practice anyhow, and would benefit every single user, and thus is worth striving for. That little detail aside (yes, I'm kidding), I'm not proposing any *radical* changes, and certainly not any additional tasks. Just an evolutionary way forward that I think would benefit everyone, in particular member projects (which would be allowed to evolve and flourish, undisturbed from any pointless discussions), and end-users, who would benefit from both more stability as well as more energy put into the components they want, without being bothered by the components they do not care about. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 20 May 2016 at 17:14, Stefan Seefeld wrote:

On 20.05.2016 11:55, Peter Dimov wrote:

...

Stefan Seefeld wrote:

...

So my counter-proposal (which I have repeatedly voiced over past years) would be to let Boost evolve into an *umbrella organization* with a relatively high degree of autonomy for *member projects* to decide for their own on things like what infrastructure tools to use (to build, test, document, to track issues and feature requests, etc.), so long as certain quality standards are maintained.

And what will this umbrella organization actually *do*?

* provide general guidelines (just as now, but relaxed) * provide infrastructure * provide administrative, financial, and perhaps legal support * do reviews to accept new member projects

Sounds fine to me.

Please note that there is one important condition that such independence would build upon: A discipline of ABI- and API-compatibility between releases, that allows downstream project B to depend on upstream project A while keeping its own release cycle. Note that, while likely being the most difficult aspect of this proposal, it's something that we have been discussing for a long time, and which would be good engineering practice anyhow, and would benefit every single user, and thus is worth striving for.

I think that's worthwhile, and not too onerous for established libraries. Could be a little more flexible for new libraries.

On 20 May 2016 at 8:12, Robert Ramey wrote:

Thanks for a good summary.

I <sniped> the whole thing in the interest of brevity. I don't intend to address the specifics of the proposal here. It would be too long and way too off topic. But I do have a couple of observations.

a) It's breathtaking in it's scope. You can't be accused of being timid. Feel free to take that as a compliment.

LOL they're just ideas Robert. Some more fully baked than others. A committee of the willing would ponder each proposed idea, maybe do a bit of prototyping, and see what's unaminously agreed by everyone there. If it's not unaminous, I don't think it should enter the 2.0 plan. You might note the strong resemblence to ISO WG21 procedures incidentally.

b) There is no way Boost could get to this place starting from where we are now by means of evolution. The gap is just too broad. You'll have to think in terms of intelligent design rather than evolution. This has been done before - after all boost itself was founded by a small group of people who decided to strike out on a whole new path.

It's a breaking change yes. As is necessary in any real reboot.

c) It would make just about every line of code in boost obsolete.

If a library maintainer wishes to port their code to something like my shim layer, their library can be compatible with both Boost 1.x and 2.x. AFIO v1 was implementing that last year, and very few of the peer reviewers even noticed (except to complain about "needless build configuration complexity"). AFIO v2, Outcome and my other Boost-ish libraries are exclusively built on that Boost-lite emulation layer, and it's sufficiently good I haven't actually used real Boost since last October.

d) This would require resources on a scale way beyond what we've seen in boost. Specifically, I'm thinking of library developers.

Once the 2.0 plan has been finalised by the committee - which I'd expect to take a minimum of a year - then begins implementation. I would assume it would happen piecemeal, as individual library maintainers get round to adapting their library to fit the new design. Parts of the plan would never be implemented because no maintainer bothered. That's absolutely fine - it means they weren't really needed after all.

Given all this, I think you're efforts in this endeavor will be wasted in boost and you'd likely get more reward starting something from scratch.

I disagree. What I propose is very like how Boost was in the early days back when earnest and passion drove evolution instead of the cynical heckling and sniping jadedness you get here now. A reboot in every sense of the word. Moreover, I'm still hoping that at some point a critical mass forms to make this happen. Until then, I wait and get on with my own libraries. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

...

I presented a plan for how to technically transition to a C++ 14 only Boost 2.0 at my C++ Now 2015 presentation:

https://goo.gl/VFFXUl

The talk was well attended, and by much of the more senior Boost community members. What does it mean 'a library is C++14 only'? I suspect it means to support >=C++14 compilers only. Does that mean I'm allowed to use only features which have been added by C++14? Not for me. For me it means it uses ar least one C++14 feature and needs a C++14 compiler. The library doesn't supports C++11 compiler nor C++14 compilers that don't support the used feature. Or does that mean a library is allowed to use all features defined in the C++14 standard? This one. This doesn't mean that it uses all of them, just that the author wants the freedom of using them.

If the former, then am I still allowed to use 'int' and 'for'?

Le 21/05/2016 à 15:23, Hartmut Kaiser a écrit : -

If the latter, Boost is already C++14 only (afaict, no library uses C++17 features yet). No in my view. Go figure. So let's drop this nonsense of declaring something C++14 only.

Tell me if my alternative view of what "C++14 only" could mean change your view. Wether we want a "C++14 only" Boost version is another thing. Vicente

Le 21/05/2016 à 18:09, Edward Diener a écrit :

On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:

...

Wether we want a "C++14 only" Boost version is another thing.

What could it possibly achieve to have a Boost with only C++11 or above libraries or a Boost with only C++14 or above libraries, as opposed to having Boost as we have it now in which each library can choose what level of C++ support it requires ? I would really like to get a technical answer, as opposed to an emotional response about "moving forward" and "looking to the future" and "serving the entire C++ community", to that question by those who propose such ideas.

I'm not saying that Boost 1.x must be stopped. Not all the members of the Boost community have the same needs. In particular, I could need a C++98 Boost version at work, but I would appreciate a C++14 at home. I have moved recently to a project using C++11 and Boost. I will comeback to you with my experience. Starting a new Boost version supporting only new compilers has two sides: starting a new version and on new compilers. What I would expect from a new Boost 2.x version? * That avoids the issues we are facing with the current Boost 1.x version. Modularity * That it is modular * That libraries manage their own version (Major.minor.patch) * That libraries manage the dependencies to other libraries without cycles. * That the included libraries ensure ABI compatibility between minor versions (I don't know how to check this) * That we manage library and point/patch versions. Delivery * That the whole Boost manages their own version also (Major.minor.patch) * That we are able to deliver independently Major, minor and patch versions. * A patch version could consists in upgrading all the libraries to its last patch version respecting the Major and Minor versions and respecting the dependencies. * A minor version would upgrade only the libraries with minor versions and respecting the Major version and the dependencies. * A Major version would upgrade all the libraries respecting the dependencies. * This means that we will need to test 3 new release branches. * Build * That we can build all with CMAKE (as it is a standard de-facto). * Other build systems could be used as well (as far as they can be installed independently) * Install * That we are able to install the libraries independently or as a whole. * Quality * That we ensure some quality KPIs. We would make use of anything available to us as static checkers, sanitizers, rules checkers, code coverage, profiling, .... * Ownership and evolution * That we work as a whole, a library shouldn't be owned only by its initial author. We need to avoid unmaintained libraries. * That any additional features are reviewed to ensure the quality we require. ... What I would expect from a new Boost 2.x version requiring C++11, C++14 or C++1z compiler support? * don't reinvent the wheel. * that it is adapted to the new compiler and library version, e.g. move semantics, initializer_list, constexpr, noexcept, .... * that it would help to identify possible issues on the standard, the compilers and standard library implementations. * that there is a C++ standard proposal that follows the acceptance of a library into Boost, either by the author or someone else ... The feedback from the Boost reviews is not the same than the feedback from the committee. * I would appreciate to have the C++14 library additions that don't depend on any additional C++14 language feature to be available for C++11 compilers in the form of an extension library (we couldn't be able to modify classes existing in C++11, but we could add new ones). The same applies for C++1z and C++11/C++14 compilers. This should help as a bridge between language versions. You may have other expectations. What the authors of such libraries could gain? * I guess that supporting less compilers would allow to have a library code that has less portability issues and that it is easier to maintain. * C++11/14 offers a lot of things that helps to simplify the code "less code more software". * ... And last, what the user of such a library could gain? * a library that works better with the new standard library * able to install the libraries independently * less bugs ( remove all the ones related to portability ) * ... Maybe it is worth having a new Boost 2.x version for C++98 that respects the Boost 2.x expectations (I have no time to work on this). I repeat myself : whether we want to do it is another question. Is it worth doing it? I don't know. It needs a lot of resources and energy. What we as a Boost community could lost having additionally these new Boost versions? Best, Vicente

Le 22/05/2016 à 21:19, Edward Diener a écrit :

On 5/22/2016 2:28 PM, Vicente J. Botet Escriba wrote:

...

Le 21/05/2016 à 18:09, Edward Diener a écrit :

...

On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:

...

Wether we want a "C++14 only" Boost version is another thing.

What could it possibly achieve to have a Boost with only C++11 or above libraries or a Boost with only C++14 or above libraries, as opposed to having Boost as we have it now in which each library can choose what level of C++ support it requires ? I would really like to get a technical answer, as opposed to an emotional response about "moving forward" and "looking to the future" and "serving the entire C++ community", to that question by those who propose such ideas.

<snip>

I repeat myself : whether we want to do it is another question. Is it worth doing it? I don't know. It needs a lot of resources and energy. What we as a Boost community could lost having additionally these new Boost versions?

Many of these are reasonable wishes. But I do not see what having a Boost version which supports only C++14 on up compilation has to do with any of them. Care to explain what facilities in C++14 on up is going to make any of your wishes happen ?

All of them. Are you requesting me you enumerate the C++11/C++14 new features? Vicente

Le 22/05/2016 à 22:51, Edward Diener a écrit :

On 5/22/2016 4:16 PM, Vicente J. Botet Escriba wrote:

...

Le 22/05/2016 à 21:19, Edward Diener a écrit :

...

On 5/22/2016 2:28 PM, Vicente J. Botet Escriba wrote:

...

Le 21/05/2016 à 18:09, Edward Diener a écrit :

...

On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:

...

Wether we want a "C++14 only" Boost version is another thing.

What could it possibly achieve to have a Boost with only C++11 or above libraries or a Boost with only C++14 or above libraries, as opposed to having Boost as we have it now in which each library can choose what level of C++ support it requires ? I would really like to get a technical answer, as opposed to an emotional response about "moving forward" and "looking to the future" and "serving the entire C++ community", to that question by those who propose such ideas.

<snip>

I repeat myself : whether we want to do it is another question. Is it worth doing it? I don't know. It needs a lot of resources and energy. What we as a Boost community could lost having additionally these new Boost versions?

Many of these are reasonable wishes. But I do not see what having a Boost version which supports only C++14 on up compilation has to do with any of them. Care to explain what facilities in C++14 on up is going to make any of your wishes happen ?

All of them.

All the things you desire are made possible by C++14 features ? A modularized set of libraries is made possible by C++14 features ? A CMake implementation for a set of libraries is made possible by C++14 features ? A continuous testing implementation is made possible by C++14 features ? A system of analysis and analyzers for code integrity are made possible ny C++14 features ?

I suspect that you have not read my message. I said

Starting a new Boost version supporting only new compilers has two sides: starting a new version and on new compilers.

All the questions above are unrelated to C++. They are associated to starting a new Boost version and state new constraints fro this new Boost.

Or is it that you just feel that if you are part of a team working on a new set of libraries dedicated to only the latest C++ standard you will have more power to implement what you want to do ?

If you read my message you will see that we can do a lot of things by resetting the basis, even for C++98.

I just don't follow that having just C++14 libraries, or even just C++11/C++14 libraries, has anything to do with the wishes that you have enumerated.

It has to be with a new Boost version with different constraints. I haven't the energy to start a new Boost version for C++98 compilers. But I will be for doing it dor C++11/C++14/C++1z. Vicente

Le 21/05/2016 à 18:53, Hartmut Kaiser a écrit :

...

...

...

...

I presented a plan for how to technically transition to a C++ 14 only Boost 2.0 at my C++ Now 2015 presentation:

https://goo.gl/VFFXUl

The talk was well attended, and by much of the more senior Boost community members. What does it mean 'a library is C++14 only'? I suspect it means to support >=C++14 compilers only. Does that mean I'm allowed to use only features which have been added by C++14? Not for me. For me it means it uses ar least one C++14 feature and needs a C++14 compiler. The library doesn't supports C++11 compiler nor C++14 compilers that don't support the used feature. Or does that mean a library is allowed to use all features defined in

...

C++14 standard? This one. This doesn't mean that it uses all of them, just that the author wants the freedom of using them. If the former, then am I still allowed to use 'int' and 'for'?

Le 21/05/2016 à 15:23, Hartmut Kaiser a écrit : the -

...

If the latter, Boost is already C++14 only (afaict, no library uses C++17 features yet). No in my view. Why not? If a library is allowed to use all features as defined by C++14 it is - by extension - allowed to use C++98 features as well. But this does not mean that it is _required_ to use C++14. Thus, Boost as it is today, is C++14 only (it does not use anything outside of it).

...

...

Go figure. So let's drop this nonsense of declaring something C++14 only. Tell me if my alternative view of what "C++14 only" could mean change your view. As said, I find the classification of a library as being 'C++14 only' to be completely useless.

...

Wether we want a "C++14 only" Boost version is another thing. So in your view 'C++14 only Boost' means that it will not compile with compilers which don't support C++14. Wouldn't it be better to talk about minimal _compiler_ requirements instead of maximal _library_ allowances?

In my view talking about this as 'library requires C++14 compiler support' would make much more sense.

Sure, Vicente

On 5/21/16 10:26 AM, Peter Dimov wrote:

Hartmut Kaiser wrote:

...

As said, I find the classification of a library as being 'C++14 only' to be completely useless.

Agreed - but maybe there is something interesting to consider. Let's call it "Boost-Lite" Boost-Lite would be subset of boost with minimal dependencies outside the standard library. So it would not include those parts of boost already incorporated inside the standard library: std::shared_ptr, etc. It would also not include boost component which which are superceeded by newer standard library features and components - no need for boost::type_of, etc. Basically, this is the way that new code is being written today. New code doesn't have to be backwards compatible becauses it's new. So Boost-Lite would be a subset of Boost. It would be all of boost with that part which is generally not necessary excluded. I realize that this is not what Naill has been proposing so it's effectively off topic. But bear with me a little. I see the appeal of Boost-Lite to those making new code (libraries and Applications) who want to keep dependencies and maintainence burden minimized. This Boost-Lite would be just a subset of Boost. A different distribution. Anyone could make it. If this is what is desired the way to go about it is to: a) Announce one's new project - Boost-Lite b) Announce a list of requirements for a library to be included in the Boost-Lite distribution. This would include the library subset I mentioned above. If the promoter wants, he could add his own favorite extra requirements - e.g. CMake (in a certain way) required. or whatever. c) Announce a list of libraries which full fill the requirements Boost-Lite specifies. Some of the newer libraries would like already qualify, Many of the older ones wouldn't and many of the older one's would be considered redundant so they wouldn't matter. d) Sit back and watch library authors to make changes or versions of their libraries which qualify to be added to Boost-Lite. If you're correct in your assessment, you'll be flood with new / updated libraries. This is serious practical proposal, you don't need to write any code, you could have started it years ago. Instead you're after us like it's our problem. Just get going and then see if how many people you can get on board. Actually, I see more application for this idea. I could easily envision someone conjuring up a special boost distribution called Boost-Embedded. This would have all he old stuff - because many embedded systems only have older compilers and can't compile C++11+ code. So maybe someone want's to distribute this. I see the ability to do things like this as potentially useful. Though I don't know if anyone things it's so important/useful to actually do some work on it. If not, of course it doesn't matter. But I would like to see us continue our slow progress on modularization. It's quite possible that C++ modules in a couple of years could have a big impact on this. Parties interested in this should participate on the relevant committees. Sorry for the long post - I'm just trying to salvage something constructive. Robert Ramey

In the context of the hypothetical C++14 only Boost 2.0, this means that the libraries have access to std::shared_ptr, std::thread and so on, which in turn means that they don't need to depend on boost::shared_ptr, boost::thread and so on. This makes it possible for a "Boost 2.0" library to be completely independent of the rest of "Boost 2.0", at least in theory. And if it's independent of the rest of the "Boost 2.0" libraries, why should it depend on, say, a common build system or a common test infrastructure? So outdated. It's $current_year!

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

On 5/21/16 12:06 PM, M.A. van den Berg wrote:

If we want to break boost into smaller subsets then I would focus on modelling dependencies and versions and have an installer. This has been tried before -there are scripts that analyse boost inter-dependencies, there has been efforts to reduce these dependencies-. Dependencies could be made conditional (conditioned on assumed compiler capabilities), but I’ve never seen that (apt-get, npm, brew). It’ll probably easier to maintain various versions of libraries: one that requires C++14, another one that works with C++98 but with more boost dependencies that help fill the 98-14 gap.

Just to be clear, I wasn't suggesting breaking boost into smaller subsets. I was suggesting that anyone who wants to create a smaller subset can freely create his own. Of course the result is the same. But the latter doesn't require any concessions or changes from Boost.

Personally I think allowing ...

Boost is a band with a reputation, it imposes requirement on libraries that help build that reputation.

A monolithic release is not an essential aspect for that ... I think that library deployment is question more or less orthogonal to other questions boost addresses. I think you're agreeing with me here. Actually, I'd prefer to see us just take a release on the master branch and let anyone who want's to "package" the release or any subset thereof. I'd like to see us get out of the distribution business entirely. Robert Ramey

On 21 May 2016, at 22:01, Peter Dimov wrote:

M.A. van den Berg wrote:

...

Personally I think allowing boost branded libraries (approved by boost, conforms to boost guidelines.. something like that) that are separately downloadable -just like any lib on Github really- can have many benefits: It allows for growth in the number of libraries, it decouples releases, abandoned libraries won’t hurt the quality of a release because there is no longer a monolithic releases.

Boost is a brand with a reputation, it imposes requirement on libraries that help build that reputation. A monolithic release is not an essential aspect for that.

That's the underlying assumption of those who press for change. What if it's wrong?

Boost releases are the signature product of Boost. What if the value of the Boost brand is substantially contained in Boost releasing quality code as a single unit that can be adopted wholesale in a single step?

What if turning Boost into a committee that merely rubber-stamps libraries would destroy the value of the Boost brand?

Incidentally, the growth in number of libraries is currently impeded not by the monolithic release, but by the review process. That is, it's the rubber stamping part that's the problem, not hypothetical entrenched evil groups of old people who hypothetically delete people's CMakeLists.txt files under the cover of the night.

Good points. How can we speed of the review process, make it more efficient? To take an extreme: Apple reviews millions of apps, the reject very quickly and have a likely a semi-automated and rational checklist that developers can self asses their submissions against. Boost submissions are much more technical so you can’t really apply such a binary checklist (even though reviews already have structure). Perhaps it’s an idea to invite (new) people to participate in the review process? Or is the level of required seniority too hard to find?

On Sat, May 21, 2016 at 5:25 PM, Robert Ramey wrote:

On 5/21/16 1:20 PM, M.A. van den Berg wrote:

...

How can we speed of the review process, make it more efficient?

One can go there download or checkout the submission, try it on his machine. And fill out a form which corresponds to the Boost Review process. The library author - or anyone else is informed of this and can respond. All this can be done before there is any formal review announced.

Just to expand on this, here's a library that is sitting in the incubator (disclaimer: I am the author): https://github.com/vinniefalco/Beast It offers implementations of HTTP/1 and WebSocket using Boost.Asio. If someone were to download and try out this library and offer some feedback, I'm sure the author would be thrilled since acting on feedback can only increase the likelihood of boost acceptance.

On 21 May 2016 at 22:20, M.A. van den Berg wrote:

How can we speed of the review process, make it more efficient? To take an extreme: Apple reviews millions of apps, the reject very quickly and have a likely a semi-automated and rational checklist that developers can self asses their submissions against.

Good idea, but not a new one. I began putting together an initial checklist of potential automatable C++ style and design checkers via a clang AST parser at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook. The idea was that people could submit their library, and get it scored and ranked on a dashboard. All automated. Even better, non-Boost library authors could use the same system as tuneups for their own code - a solution truly serving the C++ community at large, not just yet more Boost parochialism. It was not warmly received by the community. I got publicly accused of all sorts of malevolent behaviours, so I abandoned the effort and moved onto more productive uses of my time. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Sat, May 21, 2016 at 3:03 PM, Peter Dimov wrote:

Niall Douglas wrote:

...

I began putting together an initial checklist of potential automatable C++ style and design checkers via a clang AST parser at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook. The idea was that people could submit their library, and get it scored and ranked on a dashboard. All automated.

You can't automate out human judgment. And even if you could, human judgment is the basis of reputation. "A collection of libraries that have passed certain scripted checks" doesn't have the same value, because a script has no face.

+1 I would even say that it is dangerous to use some form of automated score to rate the quality of a library. The net effect will be that it'll make bad libraries look good "on paper". Library design, like any other design, can only be properly evaluated by people intimately familiar with the problem domain. Emil

On 5/21/16 4:09 PM, Andrey Semashev wrote:

Wow. Boost community is so harsh, unfair and narrow. I must say I'm amazed with your persistence in communicating with it - it sounds like it's a pure waste of your time.

The boost community open about considering ideas. It's just that not all ideas are recognized as good ones. Just the fact that some idea doesn't convince a consensus, doesn't mean that Boost is harsh, parochial, close minded, old, or whatever. It likely means that that ... the not many people consider it a good idea. This is the simplest explanation and I'm sure the correct one. What would boost look like if we accepted every idea proposed? OK too ridiculous. What would boost look like if half the ideas proposed were accepted? Still too ridiculous. Is there any idea you think should be accepted? Do you really believe that replacing the current review system with some automatic scoring system would be an improvement? Then go ahead and make your case. But don't accuse those who have made a better case of having some sort of personal failures. I know you don't mean to do this, but that's what your doing. Robert Ramey

On 5/21/16 5:13 PM, Andrey Semashev wrote:

To be clear, there was a fair bit of sarcasm in my message,

I'm embarrassed to say I totally missed the sarcasm. Guess I've been on the thread too long. Robert Ramey

On Sunday, 22 May 2016 03:28:04 MSK Emil Dotchevski wrote:

If I might add, nobody would object to automatically rating Boost libraries according to any metric whatsoever and publishing the results for anyone so inclined to read and consider.

I wouldn't agree with 'rating' libraries, but a set of automated checks would be great. Both as part of the testing process and a precondition for a library proposed for review. In addition to the normal human review, of course. We do have inspect reports run on libraries in Boost, although they don't check much beyond the basic things like copyrights and tabs. Unfortunately, I suspect not many people pay attention to them either. It might help if the inspect reports were directly visible in the test results as a test pass/failure.

On 22/05/2016 00:47, Niall Douglas wrote:

I began putting together an initial checklist of potential automatable C++ style and design checkers via a clang AST parser at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook. The idea was that people could submit their library, and get it scored and ranked on a dashboard. All automated. Even better, non-Boost library authors could use the same system as tuneups for their own code - a solution truly serving the C++ community at large, not just yet more Boost parochialism.

It was not warmly received by the community. I got publicly accused of all sorts of malevolent behaviours, so I abandoned the effort and moved onto more productive uses of my time.

Would you mind providing links the messages that accuse you of malevolent behaviours? It is my recollection that the idea of automatic checking and ranking of libraries received basically the same objection as now - that automatic tests can easily check coding guidelines, or simple numeric metrics, but they hardly can be used to evaluate design quality, documentation, or usefulness of a library. Therefore, using automatic metrics for ranking might easily down-rank good libraries that don't meet some specific criteria of yours, and alternatively up-rank libraries that are good on technical metrics but are not good for real users. For some reason, instead of assuming that this argument is made by well-meaning, remotely-intelligent and somewhat-experienced people, and therefore must be at least partially sensible, you decided to ignore it, and assume malice. In fact, could you explain what are you goals? You've laid out pretty ambiguous plan, one that would likely require a dozen of people with plenty of spare time to make even the first step. In order to promote it, you've made antagonizing remarks towards Steering Committee, followed by remarks against older people (may I know your age, for the record?), followed by further wide-ranging complaints? Would it be sensible, at this point, to either: - Create a new project, called "Niall C++ Libraries", having nothing to with Boost (you can of course use existing libraries, since the license allow that) - Decide that majority of people here have no personal agenda against you, and try to push your ideas the way Robert suggested - by preaching them carefully and not expecting immediate from-top approval? Thanks, -- Vladimir Prus http://vladimirprus.com

On 22 May 2016 at 10:53, Rainer Deyke wrote:

I like to think I'm more up to date than the average C++ user. ... The gcc that comes with my operating system is version 4.8, which predates C++ 14.

LOL - That was really really funny...

On 22 May 2016 at 11:41, Thomas Heller wrote:

What's so funny? Did I miss anything?

Possibly...

On Sun, May 22, 2016 at 06:53:36PM +1000, Vladimir Batov wrote:

On 2016-05-22 18:15, degski wrote:

...

On 22 May 2016 at 10:53, Rainer Deyke wrote:

...

I like to think I'm more up to date than the average C++ user. ... The gcc that comes with my operating system is version 4.8, which predates C++ 14.

LOL - That was really really funny...

What's so funny?.. That he is a s/w professional running LTS Ubuntu (which does have gcc-4.8) and developing real applications for real companies?

Hello Vladimir, Just to put this into perspective: Ubuntu 16.4 is an LTS release that uses g++-5.3.x. You can also install clang/llvm with apt-get to have access to two c++14 compilers, with no customization effort required. enjoy, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

On 22/05/2016 17:05, Peter Dimov wrote:

Karen Shaeffer wrote:

...

Just to put this into perspective:

Ubuntu 16.4 is an LTS release that uses g++-5.3.x.

If you're in a position in which you can afford to always install the latest LTS, you wouldn't need an LTS.

Great! From an HPC perspective: most facilities seems to run CentOS 6.x with gcc 4.4. The ones moving to CentOS 7.x will get gcc 4.8. Even if those platforms ends up using some version of Intel Compiler, it will rely on the installed gcc library/headers. Alain

I'm running an up-to-date operating system, and I switched to C++ 11 as soon as it became viable. I can do that because I'm an individual. Organizations move more slowly, and the bigger they are, the slower they move.

Not necessarilly, e.g. every Windows OS is built with the (their) latest compiler... that's why they make it in the first place (at least in the past)...

It wouldn't surprise at all to see Visual C++ 6.0 still being used

The fact that this happens doesn't make it anything less than a crime, for which any CTO should be summarilly executed...

Wikipedia even says, "Visual C++ 6.0 is still quite popular".

Don't believe everything they say on WP. The release schedule of gcc is here https://gcc.gnu.org/releases.html. Now have a look and try to figure out why I thought was pretty funny... (hint: the combination of the words "up-to-date" and "gcc 4.8")...

Am 22.05.2016 um 13:49 schrieb Rainer Deyke:

On 22.05.2016 11:12, degski wrote:

...

...

I'm running an up-to-date operating system, and I switched to C++ 11 as soon as it became viable. I can do that because I'm an individual. Organizations move more slowly, and the bigger they are, the slower they move.

Not necessarilly, e.g. every Windows OS is built with the (their) latest compiler... that's why they make it in the first place (at least in the past)...

I'm sure they do. I'm also sure that they have legacy code dating back a long time, so I don't know how modern their codebase actually is and how many C++ 14 features they actually use. Presumably they use at most the subset of C++ 14 that is actually supported by their compiler, which is a good deal less than full C++ 14.

Unless you have a deprecated feature, you won't get problems switching to C++14. If you use a deprecated feature, you should redo you code regardless, they were dropped for a reason. I don't think we should force people to use new features, but not using them in new modules because of an ancient code base just seems bad practice to me.

...

...

Wikipedia even says, "Visual C++ 6.0 is still quite popular".

Don't believe everything they say on WP.

The release schedule of gcc is here https://gcc.gnu.org/releases.html. Now have a look and try to figure out why I thought was pretty funny... (hint: the combination of the words "up-to-date" and "gcc 4.8")...

I'm using the latest version of gcc provided by the latest version of my OS. Using a later version of gcc would require either compiling from source or switching to another operating system. Yes, it's a shame that Ubuntu isn't more proactive about making more up-to-date compiler packages available, but there's nothing I can do about it.

Do you also use the boost package provided by ubuntu? Would be 1.54 then, right? There is something you can do: compile a new version and create a dpk for your coworkers. I get the thing about the codebase, but the argument "my ubuntu doesn't ship" is just nonsensical. By that logic you could not develop on windows at all, because it does not ship a compiler as part of the OS at all. You're a C++ developers so compiling from source should not be a problem. Also you can get a newer version from an experimental distribution so you don't need to compile: http://packages.ubuntu.com/de/xenial/gcc-6-base Or get clang. Saying "there's nothing I can do about it" is just plainly wrong.

Am 22.05.2016 um 15:57 schrieb Rainer Deyke:

On 22.05.2016 13:57, Klemens Morgenstern wrote:

...

There is something you can do: compile a new version and create a dpk for your coworkers. I get the thing about the codebase, but the argument "my ubuntu doesn't ship" is just nonsensical. By that logic you could not develop on windows at all, because it does not ship a compiler as part of the OS at all.

I am actually moving in that direction. I just haven't gotten all of the cross-compilers I need to compile, because: - Compiling gcc is complicated. - Compiling gcc cross compilers is more complicated. - Various third-party scripts to compile gcc cross compilers haven't worked for me, and are complicated enough that it's not obvious to me where the problem is. - I have other priorities. Of course, this only works if I distribute my work in binary form (doable in my case, but not an option for open source developers), redistribute gcc in binary form (not a serious option in my case), or require that all of my users recompile gcc (*really* not an option).

I like clang. I also like to test my code on multiple compilers, which is why I'm using clang in addition to gcc, not as a replacement.

Just out of curiosity - what platform are cross-compiling for? To be clear: I don't think it makes sense to require C++14 or something like that. I would think is is much more sensible, to keep the development version on the current standard, even with incomplete implementations and provided forked subsets for older standards. I.e. you have a guarantee for some libraries to remain C++98 compliant. But keeping new libraries on C++11 or C++98 is not very useful; that will end like the current (none-eabi) embedded world, where the majority still uses C. I just dislike the "I cannot do anything" attitude - and if my company would require me to write C++98, I'd quit. Also: some features like move-semantics are game changing, causing me to write my libraries differently; not using it would cause bad design.

Am 22.05.2016 5:15 nachm. schrieb "Klemens Morgenstern" < klemens.morgenstern@gmx.net>:

Am 22.05.2016 um 15:57 schrieb Rainer Deyke:

...

On 22.05.2016 13:57, Klemens Morgenstern wrote:

...

There is something you can do: compile a new version and create a dpk for your coworkers. I get the thing about the codebase, but the argument "my ubuntu doesn't ship" is just nonsensical. By that logic you could not develop on windows at all, because it does not ship a compiler as part of the OS at all.

I am actually moving in that direction. I just haven't gotten all of the cross-compilers I need to compile, because: - Compiling gcc is complicated. - Compiling gcc cross compilers is more complicated. - Various third-party scripts to compile gcc cross compilers haven't worked for me, and are complicated enough that it's not obvious to me where the problem is. - I have other priorities. Of course, this only works if I distribute my work in binary form (doable in my case, but not an option for open source developers), redistribute gcc in binary form (not a serious option in my case), or require that all of my users recompile gcc (*really* not an option).

I like clang. I also like to test my code on multiple compilers, which is why I'm using clang in addition to gcc, not as a replacement.

Just out of curiosity - what platform are cross-compiling for?

To be clear: I don't think it makes sense to require C++14 or something

like that. I would think is is much more sensible, to keep the development version on the current standard, even with incomplete implementations and provided forked subsets for older standards. I.e. you have a guarantee for some libraries to remain C++98 compliant. But keeping new libraries on C++11 or C++98 is not very useful; that will end like the current (none-eabi) embedded world, where the majority still uses C.

I just dislike the "I cannot do anything" attitude - and if my company

would require me to write C++98, I'd quit. It's sometimes more complicated than this. It is true however that the landscape improves. In our case, our users are mostly not programmers by profession. They use the software as a means to an end, mainly to do science. Compiling any dependencies themselves is a major burden (independent of the used build system, btw). So they use whatever is installed on the system. Due to the lifetime of those systems we need to support compilers and boost versions that date back around 5 years (we require minimal C++11 support and keep increasing the requirements step by step). I guess my point is, the C++ community does not solely consist of hard core programmers who know their way around eventually, but also people who just want to get a job done without too much hassle.

Also: some features like move-semantics are game changing, causing me to

write my libraries differently; not using it would cause bad design.

_______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

On Sunday, 22 May 2016 23:05:00 MSK Rainer Deyke wrote:

Yes, it's a shame that Ubuntu isn't more proactive about making more up-to-date

compiler

packages available, but there's nothing I can do about it.

Actually, Ubuntu is quite proactive. The latest release is 16.04 (which is also an LTS release) provides gcc 5.3.1 out of the box. Also, there is PPA[1] which provides more recent compiler versions. [1]: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ test

On Monday, 23 May 2016 12:52:17 MSK Vladimir Batov wrote:

On 05/23/2016 06:09 AM, Andrey Semashev wrote:

...

Actually, Ubuntu is quite proactive. The latest release is 16.04 (which is also an LTS release) provides gcc 5.3.1 out of the box. Also, there is PPA[1] which provides more recent compiler versions.

Actually, it's the customers who are not in a hurry to install and "play" with "latest and greatest" for obvious reasons. Unlike children who are eager to play with a new "toy" and throwing tantrums when the rest of the world is not catching up, businesses always (from my experience) a version behind... be that MS Windows or Ubuntu LTS or Solaris.

I was addressing the remark with regard to Ubuntu, which is obviously not to blame for your customers' preferences. Then, there are different kinds of customers. In some cases it doesn't really matter what OS your software is developed for - because you ship both the software and the OS. Sometimes hardware, too. But I know what you're talking about. Corporate clients don't care how the software is written as long as it gets the job done. Developers do. So it's up to the developers to push for the new language features, libraries and so on. In my practice language or library updates never came from top down in a company, always from bottom up from the initiative developers who care.

My understanding is that rushing forward well ahead of the installed customer base causes a lot of headache as I'll then have to ship libraries not present on the customer machine. Then I'll have to make sure those correct libraries are in fact used... and fix when the customer screws something up (like LD_LIBRARY_PATH). So, simple "ship-and-forget" turns into maintenance and support on site. A nightmare.

Don't forget that using the older tools becomes more expensive over time - sometimes more expensive than maintaining your own up to date environment in the older OS. And with regard to maintenance, the support contract is another (often significant, often main) source of income.

On Monday, 23 May 2016 14:40:47 MSK Vladimir Batov wrote:

On 2016-05-23 20:12, Andrey Semashev wrote:

...

In my practice language or library updates never came from top down in a company, always from bottom up from the initiative developers who care.

Well, I guess, you are luckier. :-) For us, the customer IT infrastructure is essentially carved in stone. We are free to do whatever we want... as long as it installs and works on their platform. So, the closer my development framework to their framework, the less hassle I have maintenance and support-wise.

My main point above was that unless developers start nagging the management, they will never upgrade their tools. An the management tend to understand the language of numbers. If implementing a feature suddenly takes a month instead of a week because the feature is implemented with a C++11 library, I'm sure it'll be a point in favor of maintaining a C++11 environment.

...

And with regard to maintenance, the support contract is another (often significant, often main) source of income.

Indeed. The difference is mnt/support of your s/w as opposed as opposed to mnt/support of their platform and their environment. The more components I deliver (say, due to using libs missing in their standard installation) the more vulnerable I am to their tinkering with the system. Nothing new... I am sure you are well aware of all that. It's just that that aggravated persistent noise about C++14-only... loudly claiming to represent "wider C++ community" when in fact, it could not be further from the truth. Irritating.

I won't claim that C++14 or even C++11 community is wider than C++03-only or the other way around; I don't have data to back up either theory. But I can guess that larger- scaled companies are much more conservative. OTOH smaller companies are easier in this regard, and they are more numerous. For reference, in our company we switched to C++11 in 2011 or so, slightly before the final standard paper has been announced. We were using gcc 4.4 back then - an even earlier implementation of the unfinished standard. Even then, the few core C++11 features that we had, like rvalue references (yes, even the preliminary version thereof), proved to be extremely useful in our software design. Though it may not have that much of an impact if you already have a huge C++03 code base. Anyway, what I'm trying to say is that (a) unless you, the developer, act, you will not have C++11 and (b) adoption of the newer C++ version happens faster in some environments than other (that includes commercial environments). Sorry for being Captain Obvious :)

"Paul A. Bristow" hat am 23. Mai 2016 um 15:30 geschrieben:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 22 May 2016 21:10 To: boost@lists.boost.org Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*

On Sunday, 22 May 2016 23:05:00 MSK Rainer Deyke wrote:

...

Yes, it's a shame that Ubuntu isn't more proactive about making more up-to-date

compiler

...

packages available, but there's nothing I can do about it.

Actually, Ubuntu is quite proactive. The latest release is 16.04 (which is also an LTS release) provides gcc 5.3.1 out of the box. Also, there is PPA[1] which provides more recent compiler versions.

[1]:

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test

excellent!

however, a quick search of Launchpad only finds Boost 1.55

https://launchpad.net/~boost-latest/+archive/ubuntu/ppa

How can we get the most recent Boost release (and/or master) available to Ubuntu users as easily?

I did that, years ago. My Boost PPA (https://launchpad.net/~purplekarrot/+archive/ubuntu/boost) no longer contains any packages, because the Ubuntu versions that I built them for are no longer supported. I don't remember the exact procedure, but I might find the script that I used in my archive. We could create an official Boost PPA and provide up to date packages with each release. It is no big effort. I just don't really have a use-case myself. But I can show how to set this up if there is enough interest. Cheers, Daniel

I would love to see a more actively maintained PPA for Boost on Ubuntu too, but am afraid that I don't have capacity to offer to help with that myself. On cpp-ethereum we have to maintain multiple PPAs with many more re-packagings of external dependencies than I would like. We've also got Homebrew packaging, Windows installers, DMGs for OS X, and have a "fake package repository" for our Windows binaries. I'm hoping we can start to leverage NuGet C++ on Windows, but I'm not sure if it is possible. There is Chocolatey too. The fragmented packaging story for C++ is a huge problem for maintainers and for distribution of libraries. On Mon, May 23, 2016 at 7:25 AM, Andrey Semashev wrote:

On Monday, 23 May 2016 17:21:42 MSK Paul A. Bristow wrote:

...

however, a quick search of Launchpad only finds Boost 1.55

https://launchpad.net/~boost-latest/+archive/ubuntu/ppa

How can we get the most recent Boost release (and/or master) available to Ubuntu users as easily?

I guess, someone would have to take over that PPA or create a new one. There's this note:

IMPORTANT: Due to this PPA main contributor (f4l3) disagreement with Canonical decisions and strategies, no active user is working on this PPA any more. If you are interest in helping this PPA packaging more recent versions of the BOOST library, please send an email to f4l3.

https://launchpad.net/~boost-latest

From the links in the PPA description it looks like this should have been a kind of official (?) repository, although I never heard of it before.

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

-- bob@summerwill.net

On 05/22/2016 09:53 AM, Rainer Deyke wrote:

On 19.05.2016 11:17, Niall Douglas wrote:

...

The C++ 14 only libraries contributed to date are clearly written first for C++ not Boost. They are the future we should be proactively encouraging into a new clean ground up redesigned fork of Boost, a Boost 2.0, instead of corralling them into legacy and outdated packaging, build, design, documentation and idioms out of some misguided desire for serving the legacy Boost usership before that of the wider C++ community.

What percentage of "the entire C++ community" do you think has access to a C++ 14 compiler anyway?

[...] I'd love to switch to C++ 14, but right now it's just technically viable for me.

I have to agree with that. The company I work for builds devices that run C++ code and Desktop applications to control these devices. While I'm relatively free to use whatever compiler I want on the desktop side (as long as I provide an installable package to the customer, that runs on Windows Vista+) I cannot control what is available on the device. So I have to adapt to whatever compiler version the firmware team decided to provide. The most recent compiler they provide on one of our devices is GCC 4.8. I will have to support this compiler (even when writing new code that will be running on both, desktop machines and on the devices) for years to come. As a side note, we have to support code written in Visual C++ 6.0, but these versions do not require any new Boost version, so this is not an issue. But of course we have VMs with such ancient compilers around and in use. But any new library that requires C++14 is of no use to our company, as long as we cannot make sure the code will be running in our desktop applications only (which is the majority of newly written software in our company). And this will not change quickly. A new version of Boost that required C++14 for all their libraries would not be used, even though it might be faster, better tested and have a ton of other advantages. It would be easier to write/port some new code ourselves than to force a change of infrastructure to the entire company.

On Sun, May 22, 2016 at 8:57 AM, Norbert Wenzel wrote:

But any new library that requires C++14 is of no use to our company

What about C++11? The difference between C++14 and C++11 is not that large. As a sole programmer maintaining a library offering, it wasn't too much trouble for me to restrict myself to C++11. Simply rewriting lambdas taking auto parameters into hand rolled classes, and not using library conveniences like std::enable_if_t was sufficient. But supporting anything before C++11 would require a rather large increase in the amount of change and maintenance, and more resources than I have available to devote to the project. On Sun, May 22, 2016 at 9:08 AM, Thijs (M.A.) van den Berg wrote:

If the devices are network attached then this sounds like a great usecase for testing the beast http boost library?

Note that Beast requires C++11 (see http://vinniefalco.github.io/beast/beast/intro/requirements.html)

If I may chime in briefly on the whole debate- if you watch any of the cppcon talks, or in fact talk to game devs, you'll find that many companies are heavily invested in older platforms, in fact as far back as MSVC 2008 in some cases. This is not arbitrary behaviour, it is grounded decisions either based on investiture in infrastructure or in some cases, maintaining codebases which have been in existence for long periods of time. Those companies may not be the target userbase of boost, but they might be. Do you wish to exclude them? Given that basically no compilers supported C++11 in it's entirety until very recently, I think the jump to ditch old standards support is in poor taste, even on a forward-going basis, and will exclude many potential users. Cheers, M On 23/05/2016 1:55 a.m., Norbert Wenzel wrote:

On 05/22/2016 03:27 PM, Vinnie Falco wrote:

...

On Sun, May 22, 2016 at 8:57 AM, Norbert Wenzel wrote:

...

But any new library that requires C++14 is of no use to our company

What about C++11?

Yes, C++11 is used extensively in new code and is supported by GCC 4.8. Older devices are less likely to get any new features, thus support for older compilers with new versions of Boost is probably not needed. In my reply I was specifically referring to the idea of making a C++14 Boost 2.0 subset/fork for the reason to support *the entire* C++ community, which seemed a bit contradictory from my point of view.

...

On Sun, May 22, 2016 at 9:08 AM, Thijs (M.A.) van den Berg wrote:

...

If the devices are network attached then this sounds like a great usecase for testing the beast http boost library?

Note that Beast requires C++11 (see http://vinniefalco.github.io/beast/beast/intro/requirements.html)

Thanks for that suggestion, but permanent network connection and HTTP are not available at the moment.

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

On 5/16/16 13:15, Michael Caisse wrote:

CMake now has a variety of features, including 'usage-requirements', that were inspired by Boost.Build and the work that the Boost community has done with Kitware.

I misattributed this work. It was Stephen Kelly who implemented this feature. -- Michael Caisse Ciere Consulting ciere.com

No, not at all. Hana searches for Boost 1.59 _or above_, because it supports these versions. Obviously, the CMakeLists.txt file included with Hana is not the CMakeLists.txt file that would be included with Hana if the Boost community decided to make a move to CMake, which is not the case right now.

I want to remind you that this started with "The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution." But now it is obvious Hana will need two CMakeLists.txt and somehow this is not "a maintenance burden".

On 5/18/16 10:02 AM, Paul Fultz II wrote:

On Wednesday, May 18, 2016 at 11:29:07 AM UTC-5, Mikhail Strelnikov wrote:

...

...

No, not at all. Hana searches for Boost 1.59 _or above_, because it supports these versions. Obviously, the CMakeLists.txt file included with Hana is not the CMakeLists.txt file that would be included with Hana if the Boost community decided to make a move to CMake, which is not the case right

now.

...

I want to remind you that this started with "The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution."

But now it is obvious Hana will need two CMakeLists.txt and somehow this is not "a maintenance burden".

I dont think that Louis is suggesting two cmake files. Rather, if boost were to move to cmake then the `find_package` could be used to find the actual boost targets rather then relying on cmake to reverse engineer the dependencies.

And, like I said in a previous email, a special `boost_find_package` function could be added(or we could override `find_package`) to search for internal dependencies, which will allow the same cmake file for both standalone and superproject builds.

I have to confess I'm not this. The original post on the thread stated: "We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory." Leave aside the fact this as far as I know this has never been prohibited. It seems that the request is that the stated policy incorporate the above text and that no one has actually argued against this. It seems to me that you're getting exactly what been asked for. So what's the problem? Robert Ramey

On Wed, May 18, 2016 at 12:20 PM, Paul Fultz II wrote:

Rene has made it clear that it was prohibited by the guidelines,

I have? The requirements are written in an affirmative aspect. They don't prohibit anything. And this is why I wanted *actual* wording changes. As people seem to be reading them differently. At worse the current requirements would mandate that you have two cmake files. One in the build directory, and if you wanted, one in the root. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On May 18, 2016, at 12:52 PM, Vladimir Prus wrote:

On 18/05/2016 20:20, Paul Fultz II wrote:

...

...

The original post on the thread stated:

"We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory."

Leave aside the fact this as far as I know this has never been prohibited. It seems that the request is that the stated policy incorporate the above text and that no one has actually argued against this. It seems to me that you're getting exactly what been asked for.

Rene has made it clear that it was prohibited by the guidelines, and Vladimir is opposed to it.

I am specifically opposed to permitting cmake stuff at root level of a library while requiring that Boost.Build files are in the 'build' directory. This objection can be addressed by either allowing all of that at the root (not really facetious suggestion), or by requiring that all build files be under 'build' directory - which has the advantage of actually scaling, and apparently is possible with all possible build systems. In the latter case the guidelines might be amended to say that library author can add additional build systems support, though in practice we already have makefiles and VS solutions and what not.

I’d like to see the CMake files in the same locations as the Jamfiles so we have a consistent layout for build and test across Boost.

On Thursday, May 19, 2016 at 11:46:28 AM UTC-5, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-...@lists.boost.org javascript:] On Behalf Of Belcourt, Kenneth Sent: 19 May 2016 17:18 To: bo...@lists.boost.org javascript: Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'

I’d like to see the CMake files in the same locations as the Jamfiles so we have a consistent layout for build and test across Boost.

+1

(of course, keeping the existing bjam/b2 build system and the tireless team supporting it and the massive testing system, one of Boost's really impressive features).

Paul

PS We seem to be making incredibly heavy weather on this fairly minor matter!

Making something 'standard' is generally good but if the location of Cmake stuff really proves inconvenient, we could change later without major upset?

We are saying its inconvenient and we want it changed.

On Thursday, May 19, 2016 at 3:43:01 PM UTC-5, Raffi Enficiaud wrote:

Le 19/05/16 à 19:57, Paul Fultz II a écrit :

...

On Thursday, May 19, 2016 at 11:46:28 AM UTC-5, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-...@lists.boost.org javascript:] On Behalf Of Belcourt, Kenneth Sent: 19 May 2016 17:18 To: bo...@lists.boost.org javascript: Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'

I’d like to see the CMake files in the same locations as the Jamfiles

so

...

...

we have a consistent layout for build and test across

...

Boost.

+1

(of course, keeping the existing bjam/b2 build system and the tireless team supporting it and the massive testing system, one of Boost's really impressive features).

Paul

PS We seem to be making incredibly heavy weather on this fairly minor matter!

Making something 'standard' is generally good but if the location of Cmake stuff really proves inconvenient, we could change later without major upset?

We are saying its inconvenient and we want it changed.

But... are you asking for a change, or are you trying to enforcing it?

We are asking for a change to allow CMakeLists.txt at the top-level directory of the individual library repo at the library author's discretion. We are not trying to force library authors to put a cmake there, that is up to the library author.

On Thursday, May 19, 2016 at 5:21:21 PM UTC-5, Raffi Enficiaud wrote:

Le 20/05/16 à 00:01, Paul Fultz II a écrit :

...

On Thursday, May 19, 2016 at 3:43:01 PM UTC-5, Raffi Enficiaud wrote:

...

Le 19/05/16 à 19:57, Paul Fultz II a écrit :

[snip]

...

...

...

We are saying its inconvenient and we want it changed.

But... are you asking for a change, or are you trying to enforcing it?

We are asking for a change to allow CMakeLists.txt at the top-level directory of the individual library repo at the library author's discretion. We are not trying to force library authors to put a cmake there, that is up to the library author.

Let me rephrase: are you trying to enforce the possibility for having the CMakeLists.txt at the top-level directory of individual libraries?

I don't quite understand what you are asking. How do we enforce a possibility?

Or are you asking if it would be possible, and accept any other conclusion than the one you want?

I think not being able to have a cmake at the top-level is unacceptable.

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

On Thursday, May 19, 2016 at 6:27:33 PM UTC-5, Raffi Enficiaud wrote:

Le 20/05/16 à 00:46, Paul Fultz II a écrit :

...

On Thursday, May 19, 2016 at 5:21:21 PM UTC-5, Raffi Enficiaud wrote:

...

Le 20/05/16 à 00:01, Paul Fultz II a écrit :

...

On Thursday, May 19, 2016 at 3:43:01 PM UTC-5, Raffi Enficiaud wrote:

...

Le 19/05/16 à 19:57, Paul Fultz II a écrit :

[snip]

...

...

...

We are saying its inconvenient and we want it changed.

But... are you asking for a change, or are you trying to enforcing it?

We are asking for a change to allow CMakeLists.txt at the top-level directory of the individual library repo at the library author's discretion. We

are

...

...

...

not trying to force library authors to put a cmake there, that is up to the library author.

Let me rephrase: are you trying to enforce the possibility for having the CMakeLists.txt at the top-level directory of individual libraries?

I don't quite understand what you are asking. How do we enforce a possibility?

The "possibility" in mention here is the change you are asking in the policies (possibility of having the library top-level CMakeLists.txt). "enforce the possibility for having the CMakeLists.txt at the top-level directory of individual libraries" means enforcing the change in the policies.

People have expressed their preferences that are or are not in contraction with your proposal. It is hence questionable that those change would happen in the policy, so I am asking if you consider not having those change is an option you have considered so far.

Well if boost cannot even make this small change towards improving support for cmake, then it obviously would be best to fork boost. However, a final decision hasn't been made on the matter yet, so lets not get carried away.

...

...

Or are you asking if it would be possible, and accept any other conclusion than the one you want?

I think not being able to have a cmake at the top-level is unacceptable.

This last sentence is part of what I consider enforcing (pushy).

enforcing != pushy

Le 19/05/16 à 18:18, Belcourt, Kenneth a écrit :

...

On May 18, 2016, at 12:52 PM, Vladimir Prus wrote:

On 18/05/2016 20:20, Paul Fultz II wrote:

...

...

The original post on the thread stated:

"We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory."

Leave aside the fact this as far as I know this has never been prohibited. It seems that the request is that the stated policy incorporate the above text and that no one has actually argued against this. It seems to me that you're getting exactly what been asked for.

Rene has made it clear that it was prohibited by the guidelines, and Vladimir is opposed to it.

I am specifically opposed to permitting cmake stuff at root level of a library while requiring that Boost.Build files are in the 'build' directory. This objection can be addressed by either allowing all of that at the root (not really facetious suggestion), or by requiring that all build files be under 'build' directory - which has the advantage of actually scaling, and apparently is possible with all possible build systems. In the latter case the guidelines might be amended to say that library author can add additional build systems support, though in practice we already have makefiles and VS solutions and what not.

I’d like to see the CMake files in the same locations as the Jamfiles so we have a consistent layout for build and test across Boost.

If this is a poll, I also say +1

On 5/19/16 2:39 PM, Jeff Trull wrote:

One more vote for "allow CMakeLists.txt in the places we allow Jamfiles". Let the bigger questions be addressed separately.

If anyone's interested, There are currently three libraries with CMake files in them: compute, hana, and serialization and test compute and hana have a CMakeLists.txt file in the library root as well as other CMakeLists.txt files in subdirectories. test is a compiled library that has CMakeLists.txt files in it's build and test subdirectories serialization is a compiled library that has one CMakelists.txt file in a subdirectory named CMake There's quite a bit of variety among all these implementations. Looking at them, it would be alot of work to reconcile them. Given my esperience with CMake scripting this is not a surprise. I found in my case that it required lots and lots of trial and error and I never felt I really had it "right". I just stopped when it created my XCode project. No one's ever complained about it, so I'm really doubtful that anyone has ever tried aside from my self. My Xcode project builds and tests about 1000 tests - it takes a while to start up since it seems that XCode likes to pre-compile everything it can in order to make intellisense work. Building is pretty fast and text execution is very fast. I've been using it for about two (or three?) years without much problem (once it gets setup !!!) so that speaks well for it. From my perspective, the main attraction is that it sets up my XCode project correctly - for 1000 tests this is a big deal. With my old msvc setup setting up such a project by hand was an ongoing pain. When I want to run my "official" boost tests I use boost build with all the compilers I have on this machine in debug/release static/shared 32/64. This takes a while. Then I check in the changes and watch fail on environments I don't have. I don't really have a point there, just a little factual experience to keep things in perspective.

Le 20/05/16 à 00:09, Paul Fultz II a écrit :

There is already library's that do this(such as hana and compute),

This is not an argument.

so there hasn't been a technical problem with the tooling.

Nobody said there is one, people rather said there is no technical issue in having your CMakeLists.txt in ./build or ./cmake or ./anyothersubdir (something that you seems to omit quite often).

However, we would like the wording in the guidelines to state in a more explicit manner that this is acceptable in order to avoid possible future problems.

There is an *IF* missing there.

Le 20/05/16 à 00:55, Paul Fultz II a écrit :

On Thursday, May 19, 2016 at 5:29:14 PM UTC-5, Raffi Enficiaud wrote:

...

Le 20/05/16 à 00:09, Paul Fultz II a écrit :

...

There is already library's that do this(such as hana and compute),

This is not an argument.

...

so there hasn't been a technical problem with the tooling.

Nobody said there is one, people rather said there is no technical issue in having your CMakeLists.txt in ./build or ./cmake or ./anyothersubdir (something that you seems to omit quite often).

Yes there is a technical as well as a usability issue with hiding the cmake file in some directory. This causes problems with other tools. You will no longer be able to install a boost library with `cget install boostorg/hana`. Instead the user will have to manually download the repo, unpack the archive, and then do `cget install hana/build`. I find that unacceptable.

To be honest, I do not care at all about cget. I would like rather to see cget support another way of working. In terms of hiding, whether it is at the top-level directory or any subdirectory does not change much: it is buried deep down in a big tree in both cases. If someone wants to distribute his library outside of boost, what about having the same patch system as for eg. Debian packages wrt. upstream?

Library authors who support cmake do not want their support treated as a second-class citizen.

Yet, the primary focus of a boost library is not its good cmake support.

...

...

However, we would like the wording in the guidelines to state in a more explicit manner that this is acceptable in order to avoid possible future problems.

There is an *IF* missing there.

Where?

At the very beginning: *IF* there is some agreement (I am not in a position to say what is an agreement) and the policies are changed according to what you want. Your sentence [1] suggest that having a library top-level CMakeLists.txt is already granted. Raffi [1] Sentence: "However, we would like the wording in the guidelines to state in a more explicit manner that this is acceptable in order to avoid possible future problems."

On 5/19/16 4:43 PM, Paul Fultz II wrote:

On Thursday, May 19, 2016 at 6:12:07 PM UTC-5, Raffi Enficiaud wrote:

...

Yet, the primary focus of a boost library is not its good cmake support.

It is for hana.

I looked through he CMakefiles for hana. It came to almost 800 lines. Obviously I just skimmed them. I don't see very many developers spending the extra effort to support this. Then I decided to test it out on my system. I fired up my CMake program, pointed the source directory to hana and pointed to new build directory and let'er rip. I got three error messages - Couldn't find Boost, couldn't find Ruby and couldn't find doxygen. This is pretty normal. I don't have ruby nor doxygen on my system so I'll just ignore stuff. I always have to find the boost directory manually - probably because I don't use a command line switch. I fixed that and the complaint about using boost went away. If found the CMake generated the xcode project in the expected place and opened it up. It takes forever (an hour!) for XCode to index the whole thing. This has nothing to do with hana or cmake of course. There are just a huge amount of tests and examples there. It does it all. With boost build, I can just point to one of subdirectories and build that. I don't know if this is possible with CMake. I'm doubtful as it seems that there's a lot of code in the library root CMakeLists which wouldn't be seen if I pointed to a sub directory. One odd thing is that I have an ALL BUILD target but I don't have a RUN_TEST target. On my own CMake project I get both. ALL_BUILD just builds the executables and RUN_TEST executes them. I can't explain this. After this discussion about the importance in the location of the CMake file. I was surprise to find that - aside from what was mentioned above, there is no distinguishable difference between the process and result between the hana build/test and the serialization one. The serialization one doesn't have a top level CMakeLists.txt. In fact it doesn't even have CMakeLists.txt in any directory other than cmake. So I can't see why this has any importance at all. I certainly doesn't in my case. There has been mention of the necessity to have a top level CMakeLists.txt in order to respect convention so other tools work. I searched for other tools which might depend upon this and didn't find any. I understand that there is a convention of sprinkling these files around including the top level, but I could find anything that might depend on a particular structure.... except cget. I had never heard of this tool. All I found was a git hub project authored by you. It has only 1 contributor, and has been forked exactly once. Unfortunately, github doesn't record the number of times it's been cloned. I read the Readme page which describes it's function. It refers to something called pip which I have no idea about what it is. And a fairly elaborate procedure. I can't imagine the function of such a tool would be given that all one has to do with CMake is download, unzip and invoke CMake. It can't be easier than that process. This is the only reference I've found to cget via a google search. I have to conclude that it's a niche product and not really relevant here. So there you have it. I just can see any real need to have CMakeLists.txt in the library root. I understand it's a convention, but no one seems to depend upon it. So I would just suggest that you do what the we library authors have done. Just include CMakeLists in your subdirectories next to Jam files and make it work. If this is intolerable for your library, just include it in the root of your library and wait for someone to complain. I doubt anyone ever will. Also, a little friendly advice. You might want to refrain from suggestions that you're going to clone boost - especially over such a ridiculously trivial issue. It makes you look silly and hard to take seriously. Robert Ramey.

But if boost can’t make this trivial change to better support cmake, then it would be hopeless for future changes in boost for better cmake support.

I don't really have a stake in this, but I think this is the reason why this discussion is so awkward. It seems that 'CMakeLists.txt' is seen by both opponents and proponents as a foot in the door for future changes in Boost for better cmake support. I can understand existing library maintainers being worried about having to support cmake in the future (or risk looking arcane). And likewise I can understand new library developers keen on using the widespread cmake (and reaching more users). Sorry for butting in, but it seems you are being foot-fetishists and only indirectly discussing the real issue.

On May 20, 2016, at 8:25 AM, Peter Dimov wrote:

alex wrote:

...

...

But if boost can’t make this trivial change to better support cmake, > then it would be hopeless for future changes in boost for better cmake > support.

I don't really have a stake in this, but I think this is the reason why this discussion is so awkward. It seems that 'CMakeLists.txt' is seen by both opponents and proponents as a foot in the door for future changes in Boost for better cmake support.

Yes.

Incidentally, and ironically, a CMake-ified Boost that duplicates our current Boost.Build setup would probably have its CMakeLists.txt files in build/, so that the top level can glob for build/CMakeLists.txt. Globbing for CMakeLists.txt finds too many subdirectories you don't really want to find. (And status/CMakeLists.txt will glob for test/CMakeLists.txt, perhaps.)

Globbing for ‘libs/*/CMakeLists.txt` will only find the top-level cmake files. Also, globbing in cmake(just like unix) is not recursive(although cmake has an option to make it recursive).

$BOOST_ROOT CMakeLists.txt status/ CMakeLists.txt

These two can be folded into the top-level one, of course, if we want to follow established CMake practice. I'm just replicating the current arrangement as an illustration.

Paul Fultz II wrote:

I think a better approach is to first defined a cmake module with common functionality for boost libraries(such as creating tests and packages).

Where? In standalone deployments of e.g. Hana, the superproject isn't present, so this module would need to be somewhere in libs/hana. Which means that it can't be common.

On 5/20/16 6:25 AM, Peter Dimov wrote:

alex wrote:

...

...

But if boost can’t make this trivial change to better support cmake, then it would be hopeless for future changes in boost for better cmake > support.

I don't really have a stake in this, but I think this is the reason why this discussion is so awkward. It seems that 'CMakeLists.txt' is seen by both opponents and proponents as a foot in the door for future changes in Boost for better cmake support.

Yes. Yes again.

Incidentally, and ironically, a CMake-ified Boost that duplicates our current Boost.Build setup would probably have its CMakeLists.txt files in build/, so that the top level can glob for build/CMakeLists.txt. Globbing for CMakeLists.txt finds too many subdirectories you don't really want to find. (And status/CMakeLists.txt will glob for test/CMakeLists.txt, perhaps.)

At least the way I use CMake this isn't a problem. I just point the GUI to the top CMakeLists.txt file whereever it happens to be. Simple as pie.

...

I can understand existing library maintainers being worried about having to support cmake in the future (or risk looking arcane).

Speaking for myself, I have no problem at all with supporting cmake at some point in the future, if necessary.

Right. If more new library authors support it, and more users expect it, And standard customs evolve and perhaps a CMake Template for making scripts gets written and perhaps someone writes a document on CMake customs and best practices with regards to Boost, it will become a defacto requirement. QuickBook has a similar history. Having or not having a CMakeLists.txt file at the library root won't matter either way. Robert Ramey

On May 20, 2016, at 10:30 AM, Robert Ramey wrote:

On 5/20/16 3:51 AM, Paul Fultz II wrote:

...

You don’t know what pip is?

Absolutely no idea. I even tried googling it.

...

...

And a fairly elaborate procedure. I can't imagine the function of such a tool would be given that all one has to do with CMake is download, unzip and invoke CMake. It can't be easier than that process.

Thats a lot more steps than just `pip install cget`.

LOL - maybe if I knew what pip was and had it installed on my machine.

pip comes installed on most operating systems except windows.

The procedure I used was only a couple of easy steps and already familiar to me. I'm doubtful I'm alone in this.

...

...

This is the only reference I've found to cget via a google search. I have to conclude that it's a niche product and not really relevant here.

cget doesn’t do any magic. As it says in the readme, it just runs the equivalent of these commands on a package:

mkdir build cd build cmake .. cmake --build . cmake --build . --target install

If this is all it does, then I don't see the point of this. All this effort to replace 5 lines of text with one?

Well it does more than those lines above. It downloads the package and unpacks it. It also sets the prefix path so cmake will find the dependencies that have been installed and it will setup the install prefix. It also handles removing packages that have been installed(including packages that depend on it), and it will automatically download and install dependencies as well. That saves a lot more than 5 lines of text.

Why not just make a macro?

A macro? What are you talking about?

You'd have to make a better case that this is a saving of some sort.

...

This is what people already do to build and install something from cmake.

LOL - not me - I've never used the command line version of CMake. I'm sure I'm not alone in this either.

...

...

So there you have it. I just can see any real need to have CMakeLists.txt in the library root. I understand it's a convention, but no one seems to depend upon it.

So I would just suggest that you do what the we library authors have done.

The library authors of hana and compute include a top-level cmake. Y

ou are the only author that doesn’t, and your cmake is not useful for installing the library, either.

The cmake in serialization is only useful for you as a developer.

Maybe. Certainly that was my only interest in making it. That's why i surprised when I could discern no difference in the functionality between the one I made and the one included with hana when I tried it.

I'm also not getting what it means to install a header only library. It looks like it's just moving an include directory. Is that it?

Well it copies the header files. A library might also install cmake packaging or pkgconfig to handle dependencies.

I have been unable to discern any difference in the operation of the CMake process which derives from the location of entry file.

...

...

Just include CMakeLists in your subdirectories next to Jam files and make it work. If this is intolerable for your library, just include it in the root of your library and wait for someone to complain. I doubt anyone ever will.

I believe library authors such as Louis do not want to hide the cmake file. Having it at the top-level makes it clear and obvious that the library

supports cmake. The user doesn’t have to search through documentation to find the “special” instructions for building with cmake, instead they can build and install the library using the same steps that is used for every other library that supports cmake.

Really, the presence of CMake support is absolutely obvious to anyone who knows anything about CMake. It's not hidden.

Hiding the cmake in another directory is not obvious. I don’t see a cmake file, I assume the library doesn’t build with cmake. You could do all this manually, but the point of a tool is you don’t have to. Let the computer do the work for you, instead of the computer making you work.

...

...

Also, a little friendly advice. You might want to refrain from suggestions that you're going to clone boost - especially over such a ridiculously trivial issue. It makes you look silly and hard to take seriously.

But if boost can’t make this trivial change to better support cmake, then it would be hopeless for future changes in boost for better cmake support.

My experiments convince me that this change is not only trivial, it's absolutely unnecessary and will not effect the future of CMake as it relates to Boost one way or the other. It's totally pointless.

Look at the upside, now if CMake fails to take hold on the more than the two libraries which now support it (3 if you include mine), out of the 130 that are there, you can always say - it's all because the Boost Oliarchy wouldn't endorse putting CMakeLists.txt in the library root directory!!!

Most newer libraries coming into boost are supporting cmake, and its growing. My libraries support cmake as well. So this list will get larger.

On 5/20/16 9:35 AM, Paul Fultz II wrote:

pip comes installed on most operating systems except windows.

Not on my Mac OSX machine. $pip -bash: pip: command not found $

Most newer libraries coming into boost are supporting cmake, and its growing. My libraries support cmake as well. So this list will get larger.

FWIW - I looked at the libraries in the incubator. There are currently 32 libraries there. The following 15 have CMakeLists.txt in the top level: Tick, Segemented Tree, Safe Numerics, MetaParse, Metal, Json, http, hana, Fit, Dependency Injection, cpp.netlib, Compute, Callable Traits, Beast, Actor. This is about 1/2 which is more than I thought. Robert Ramey

On May 23, 2016, at 2:26 AM, Gavin Lambert wrote:

On 20/05/2016 22:51, Paul Fultz II wrote:

...

cget doesn’t do any magic. As it says in the readme, it just runs the equivalent of these commands on a package:

mkdir build cd build cmake .. cmake --build . cmake --build . --target install

This is what people already do to build and install something from cmake.

That's not going to work very well for a Boost library anyway, since they already contain a build subdirectory that is not intended to be an output directory. So the usual cmake trick of deleting the build directory to clean things will break the library.

cget doesn’t actually create the build directory in source to avoid these problem. Although it is quite common for users to build with cmake this way.

On the other hand, if you found the "root" CMakeLists.txt in build/ or in cmake/ first, and then run the above commands from that directory, then they would work as expected.

Except there is no way to know it is the ‘root’, except that it is at the ‘root’. Instead the user tells cget or cmake what the ‘root’ is instead of trying to guess.

On Monday, May 23, 2016 at 6:23:06 PM UTC-5, Gavin Lambert wrote:

On 24/05/2016 00:56, Paul Fultz II wrote:

...

...

On the other hand, if you found the "root" CMakeLists.txt in build/ or in cmake/ first, and then run the above commands from that directory, then they would work as expected.

Except there is no way to know it is the ‘root’, except that it is atthe ‘root’. Instead the user tells cget or cmake what the ‘root’ is instead of trying to guess.

As you said, though, that complicates things if you're automatically building dependencies rather than the main project they requested. (Which I think I recall you saying was a feature of cget.)

It seems to me that a reasonable heuristic is to use a CMakeLists.txt at the root if one is there; failing that, look in cmake/ and build/ subdirs (in that order).

Perhaps, but I don't see a need to do that because libraries don't hide there cmake in another directory(not even boost libraries). Also, it is somewhat bad practice to put the root in a subdirectory(especially when there could be cmake files in other directories) as it makes directory scope confusing to understand. Furthermore, with bjam you cannot have a root jamfile hidden in a subdirectory, either. So there really isn't a precedent for this even with boost.

Having said all that, I'm dubious about using cmake to automatically build Boost library dependencies in the first place.

Well of course, there isn't really a cmake build for boost, right now.

The way I typically use Boost (and I'm sure I'm not alone in this) is to either use the pre-built packages (for Windows or Linux) or if I need something newer, to use B2 to build the complete set of libraries myself and then point other projects at those pre-built versions, rather than to build individual sub-libraries for each project parent.

But then you have to handle the dependencies on your own, unless you use bjam all the way through.

On 20/05/2016 10:55, Paul Fultz II wrote:

...

Nobody said there is one, people rather said there is no technical issue in having your CMakeLists.txt in ./build or ./cmake or ./anyothersubdir (something that you seems to omit quite often).

Yes there is a technical as well as a usability issue with hiding the cmake file in some directory. This causes problems with other tools. You will no longer be able to install a boost library with `cget install boostorg/hana`. Instead the user will have to manually download the repo, unpack the archive, and then do `cget install hana/build`. I find that unacceptable.

This is a defect in cget, if it does not expect/allow CMakeLists to be in a subdirectory. They are never supposed to be in the output directory of cmake (which defaults to the current directory), after all, so you always have to tell cmake where to find them.

On May 19, 2016 8:56:55 PM EDT, Paul Fultz II wrote:

On Thursday, May 19, 2016 at 7:30:07 PM UTC-5, Gavin Lambert wrote:

...

...

Yes there is a technical as well as a usability issue with hiding

...

cmake

...

file in some directory. This causes problems with other tools. You will no longer be able to install a boost library with `cget install boostorg/hana`. Instead the user will have to manually download the repo, unpack

the the

...

...

archive, and then do `cget install hana/build`. I find that unacceptable.

This is a defect in cget, if it does not expect/allow CMakeLists to be in a subdirectory. They are never supposed to be in the output directory of cmake (which defaults to the current directory), after all, so you always have to tell cmake where to find them.

'hana/build' is not the output directory, it is the directory where the guidelines says to put the cmake file. It is confusing, I know.

Also, there is no defect in cget. cget just calls cmake on whatever directory you give it. cget can also unpack a tar file and call cmake on that as well. It can also download a file, untar it, and call cmake on that as well.

cget could take the subdirectory as an argument and use it after untarring, etc. The lack of that feature could be considered a defect. ___ Rob (Sent from my portable computation engine)