On Sat, Jun 24, 2017 at 10:25 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

On 6/24/17 7:20 AM, Vinnie Falco via Boost wrote:

...

On Sat, Jun 24, 2017 at 1:59 AM, Peter Dimov via Boost wrote:

...

I've done a proof of concept for (2), which can be seen here:

https://github.com/pdimov/boost-cmake-demo-2

Thank you for investing the time to produce this demo.

I have identified the following (separate) scenarios:

...

I don't know if its listed, but I am very interested in generating Visual Studio project files for certain Boost projects. I would be more motivated to help with the maintenance of any Boost library for which I can use my IDE, since I can set breakpoints and I am generally proficient with it.

First of all, I'd like to say that root post of this thread is very helpful in clarifying the options and costs and value for each one.

FWIW - I'm interested in this as well. I used the VS IDE for maintaining the Boost.Serialization library. It was very convenient to build, test, (especialy) debug the library. But it was a huge pain to setup and maintain for the hundreds targets. I swithed to Mac as my main development platform. It comes with Xcode. Setting this up to build, test and debug the library was even worse on this platform. Having spent some time figuring out CMake to compile information/advice on the incubator, I was able to make CMake files to build the serialization library. I had to deal with CMake quirks, FindBoost quirks etc. But now I can easily create a new XCode project from the CmakeLists.txt files which is a huge relief. It's much easier than trying to use XCode directly. The CMake files them selves are that complex - after you spend a lot of time fiddling. But now that's done and mostly a bad memory. The CMakeList.txt files are part of the Boost Serialization Library distribution so anyone is free to look at it to see what I had to do. I would hope that these file could also generate IDE project files for VS as well as Eclipse with no changes. But I'm not in a position to test that proposition. Note that this links with other boost libraries created with b2.

So I would add 7) or 8): Use CMake to generate an IDE project to build/test a particular library.

I've seen the innards, surface, and operation of the VS and Xcode projects generated by cmake and I'd loath to to use them. Hence I ask.. Would it be better to generate those with something else? Especially something that maps more directly to the b2 definitions. I don't know what else exist to do this. But just wondering since we are talking about a much smaller audience than N<5. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Sat, Jun 24, 2017 at 10:48 AM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

I've seen the innards, surface, and operation of the VS and Xcode

On Sat, Jun 24, 2017 at 8:45 AM, Rene Rivera via Boost wrote: projects

...

generated by cmake and I'd loath to to use them.

I can't speak for Xcode but I've been using the VS projects for a while now and they are great. I've written a couple of quality-of-life functions to help group source code into the folders. Check it out: http://i.imgur.com/dBWLuUn.png

Can you be more specific about what issues you have with generated VS projects? Perhaps they are easily addressed.

One of the issues that I've seen is that the generated project files are just shells around cmake invocations of all kinds. As opposed to direct project declarations. Which means that they are susceptible to parallel build bugs in cmake and make it awkward to deal with them past just building. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Sat, Jun 24, 2017 at 11:01 AM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

On Sat, Jun 24, 2017 at 9:00 AM, Rene Rivera via Boost wrote:

...

One of the issues that I've seen is that the generated project files are just shells around cmake invocations of all kinds. As opposed to direct project declarations.

I haven't seen that (but if you say it exists I don't doubt it). My cmake-generated projects are 100% authentic Visual Studio projects which build on their own without invoking cmake. So it is possible, if the library author wishes, to generate good .vcxproj files.

Perhaps it depends on what features of cmake you use.. I only know enough cmake to deal with build problems in client projects. And the ones I've dealt with tend to use the gamut of cmake features. Particularly the install targets. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

One of the issues that I've seen is that the generated project files are just shells around cmake invocations of all kinds. As opposed to direct project declarations. Which means that they are susceptible to parallel build bugs in cmake and make it awkward to deal with them past just building.

The project files generated by cmake are native to that build system. cmake injects a prebuild call to cmake to check if any cmake files have been changed, if so it rebuilds the build system and rebootstraps the build. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 24 June 2017 at 19:00, Rene Rivera via Boost wrote:

... and make it awkward to deal with them past just building.

+1, if I can grok it I usually end up creating a new project from scratch, just to get rid of the CMake stuff so the IDE does not lead a parallel life and does what *I* want it to do. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On 6/24/17 8:45 AM, Rene Rivera via Boost wrote:

On Sat, Jun 24, 2017 at 10:25 AM, Robert Ramey via Boost <

...

So I would add 7) or 8): Use CMake to generate an IDE project to build/test a particular library.

I've seen the innards, surface, and operation of the VS and Xcode projects generated by cmake and I'd loath to to use them.

As far as Xcode is concerned, the projects might be better. The file hierarchy in the IDE has an extra layer. Tests aren't aren't compatiple with the xcode test setup. I don't know if that's a problem since I don't know what the xcode setup provides. Also it doesn't seem to correctly setup the search directories for include files - I have to tweak that by hand. Sooo you're probably correct in the idea that a the XCode project isn't as good as one that I'd make "by hand" ... if I had nothing else to do. But it does permit me to "BuildAll" or build any particular target. It permits me to pick a target and execute it and/or debug it. It does execute my "carpet bombing" serialization library test suite. When something changes - some global option or something - I can just regenerate the IDE and it's all consistent. So all in all it works well for me. When I think i'm done, I run my traditional b2 build/test with each compiler I have available with all build,link variants - 4 and use library status to make my giant test matrix table. This has about 1200 cells - should have no red cells in order to check it in. In other words, I really only use the CMake generated IDE in order to edit source code run a smaller number of tests and debug/trace programs.

Hence I ask.. Would it be better to generate those with something else? Especially something that maps more directly to the b2 definitions. I don't know what else exist to do this.

Hmmmm - maybe you want to add a target type xcode or visual studio or eclipse to b2 in order to generate these ides instead of executables. Seems to me to be within the original concept of Boost Build - to be able to build anything from a Jamefile.

But just wondering since we are talking about a much smaller audience than N<5.

I have no idea how many people would like to work this way. It doesn't really matter as CMake with does an OK job for me with the current setup. Robert Ramey

Rene Rivera wrote:

Since I'm OCD about "extra" stuff I ask.. Would it not be better to have the user run a command *after* cloning the submodules and dependencies that generates all this for them?

Not sure how this would work. BoostVersion.cmake and default.cmake are not generated, they are just copies to enable libraries to stand alone. dependencies.cmake is generated, but you need all of Boost to generate it, so it's much easier to do that as part of a build process that is applied to the full superproject.

On Sat, Jun 24, 2017 at 10:57 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

On 24.06.2017 04:59, Peter Dimov via Boost wrote:

...

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios:

I'm a bit confused by the listing, as you use the term "user" in quite different ways.

...

1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).

2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.

3. The user uses CMake to install an individual Boost library, which is then available for find_package.

4. The user uses CTest to run the tests of an individual Boost library.

5. CMake is supported as a way to build and install the entire Boost, in place of b2.

6. CTest is supported as a way to run the tests for the entire Boost, in place of b2.

All but 1) are addressed at boost developers, i.e. people who want to build (, test, etc.) boost itself. Only 1) is concerned about users who want to use boost as external dependency to their own project.

I've been a "user" of Boost doing #2 in some of my projects. And I wrote b2 support to enable that use case (non-instrusively and external -- unlike this concept -- so far) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

So what's the reason you prefer (at least in that context) building boost as an integral part of another project, rather than referring to it as an external (pre-installed) dependency ?

Depends on the project... But generally because I need precise control over the compilation variant and want it to be uniform over all the external dependencies. That precise control offers the advantage of isolated and predictable building for the project regardless of who builds it (other devs and CI). In other projects it's the only option available as creating installed libraries is not an option. Specifically when I'm using emscripten for C++ web development. And since I use b2 in my projects I have the luxury of referencing the build descriptions in Boost directly. And hence I can understand the desires of people with other build systems to do similarly. But at the same time I've also done non-intrusive building of many different external libraries (i.e. using b2 to build autotools, make, cmake, etc projects [1]) so I know it's somewhat presumptuous to expect library authors to cater to every pet build system out there. And instead prefer authors to document, in prose, how to build their libraries. [1] I've also done that type of building in other build systems. Mostly proprietary ones I can't talk about here though. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

AMDG On 06/24/2017 10:34 AM, P F via Boost wrote:

In fact, boost also follows scenario #1, as it doesn’t build zlib or bzip2 as part of its build, but rather tries to use a prebuilt binary.

That's only half true. The default behavior is to find prebuilt zlib and bzip2 binaries, but it can also build them from source if you set ZLIB_SOURCE or BZIP2_SOURCE. In Christ, Steven Watanabe

On Jun 24, 2017, at 12:10 PM, Rene Rivera via Boost wrote:

On Jun 24, 2017 11:34 AM, "P F" mailto:pfultz2@yahoo.com> wrote:

...

On Jun 24, 2017, at 11:17 AM, Rene Rivera via Boost wrote:

On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...

So what's the reason you prefer (at least in that context) building boost as an integral part of another project, rather than referring to it as an external (pre-installed) dependency ?

Depends on the project... But generally because I need precise control over the compilation variant and want it to be uniform over all the external dependencies.

But isn’t that what a package manager does? The point of scenario #1 is that it enables a package manager or dependency tool to do this.

I've been doing this before package managers existed that could do that. And so I haven't found a package manager that will do it as flexible as I need.

What flexibility do you need?

The small number of times I've used package managers I've wrapped them in scripts that provide repeatable installation for my fellow developers.

What areas does it lack repeatability? Both conan and cget provide a toolchain definition and pulling down the specific versions. Just curious as to what other areas lack repeatability.

...

That precise control offers the advantage of isolated and predictable building for the project regardless of who builds it (other devs and CI).

Yea, but for open-source libraries and distros, they will never build the software exactly the same way. It can be built in a lot of different scenarios. This is why autotools came about to handle this.

Except for Boost I don't do open source. All my work is closed source products. Usually games or game development tools. Where developers doing installation is counter productive.

Yes, and scenario #2 works great for internal or proprietary builds.

On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost wrote:

On 24.06.2017 04:59, Peter Dimov via Boost wrote:

...

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios:

I'm a bit confused by the listing, as you use the term "user" in quite different ways.

...

1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).

2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.

3. The user uses CMake to install an individual Boost library, which is then available for find_package.

4. The user uses CTest to run the tests of an individual Boost library.

5. CMake is supported as a way to build and install the entire Boost, in place of b2.

6. CTest is supported as a way to run the tests for the entire Boost, in place of b2.

All but 1) are addressed at boost developers, i.e. people who want to build (, test, etc.) boost itself. Only 1) is concerned about users who want to use boost as external dependency to their own project.

...

At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck.

To be honest, I don't quite understand 2). Why do you want to support building boost (or parts of it) as an integral part of something else ? Modularity and encapsulation doesn't seem to have any value to you, or does it ?

As good as modularity and encapsulation sound they make it very hard to test code. Even different distributions sometimes patch packages of the same version the same without anyway to detect this. If you don't build boost as part of your program you can't certify its bug free with tests. And forget certification of bug free between different versions of boost! It is simply not an option to rely on external libraries when stuff must test clean. What mechanism you use to do this various but modularity and encapsulation are a dream.

...

5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works.

I agree. (In particular, I very much doubt that you'll get the required buy-in from all maintainers. I for once am strongly opposed to adding another bit of infrastructure to my project, which I won't be able to maintain myself.)

Stefan

--

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

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

Stefan Seefeld wrote:

Huh ? Test what code ? As a boost user I want to test *my* code, not boost.

You want to test your code in the same environment that has generated the bug report. Since so much of Boost is header-only and inlined into your code, the two are irredeemably intertwined. It's not that using the system-installed or user-installed Boost wouldn't work, it would, that's just a different workflow and a different scenario. It's a difference in philosophy and the two schools of thought don't seem to understand each other. Plus, it's just plain easier to tell people "`git clone --recursive my-wonderful-repo` and run CMake."

As a boost user I need to know that some change someone put into master on any given release to fix bug A did not introduce bug B. In practice this means my tests need to be well designed enough to test if boost breaks. As an example there was a heisenbug a few years ago in UUID where compare randomly broke on SIMD machines. To be able to diagnose bugs like this you need the exact build of boost to be a known quantity down to the compilation switches. Plus sometimes you run on new compilers that might have separate ABIs/features then the packages you could download with a distro. On Sat, Jun 24, 2017 at 10:22 AM, Stefan Seefeld via Boost wrote:

On 24.06.2017 12:08, Gary Furnish via Boost wrote:

...

On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost wrote:

...

On 24.06.2017 04:59, Peter Dimov via Boost wrote:

...

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios: I'm a bit confused by the listing, as you use the term "user" in quite different ways.

...

1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).

2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.

3. The user uses CMake to install an individual Boost library, which is then available for find_package.

4. The user uses CTest to run the tests of an individual Boost library.

5. CMake is supported as a way to build and install the entire Boost, in place of b2.

6. CTest is supported as a way to run the tests for the entire Boost, in place of b2. All but 1) are addressed at boost developers, i.e. people who want to build (, test, etc.) boost itself. Only 1) is concerned about users who want to use boost as external dependency to their own project.

...

At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. To be honest, I don't quite understand 2). Why do you want to support building boost (or parts of it) as an integral part of something else ? Modularity and encapsulation doesn't seem to have any value to you, or does it ?

As good as modularity and encapsulation sound they make it very hard to test code. Huh ? Test what code ? As a boost user I want to test *my* code, not boost. (Of course, that doesn't prevent me from also playing the role of a boost developer / tester, but that are two very different things.

...

Even different distributions sometimes patch packages of the same version the same without anyway to detect this. If you don't build boost as part of your program you can't certify its bug free with tests. And forget certification of bug free between different versions of boost! Yeah, now we are plainly in the discussion of Boost's lack of API and ABI stability.

...

It is simply not an option to rely on external libraries when stuff must test clean. I strongly disagree. Rigorous testing (which includes the clear distinction between unit testing and integrated testing) doesn't invalidate encapsulation. Quite the opposite !

...

What mechanism you use to do this various but modularity and encapsulation are a dream.

Very sad, but luckily doesn't reflect my experience.

Stefan

--

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

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

On 24.06.2017 12:29, Peter Dimov via Boost wrote:

Stefan Seefeld wrote:

...

To be honest, I don't quite understand 2). Why do you want to support building boost (or parts of it) as an integral part of something else ?

That's a common workflow. Your (non-Boost!) library or project keeps all of its dependencies in ext/ and "consumes" them from there using add_subdirectory from CMake. This is what boost-cmake-demo-2 shows. This is not a way to support building Boost, this is a way to support using Boost libraries as part of some user project, without needing to build and install (the entire) Boost.

...

Modularity and encapsulation doesn't seem to have any value to you, or does it ?

Not sure what you mean here. You ask me why do I want to support building only parts of Boost,

No, that wasn't my question.

then ask me whether modularity has any value to me. You must be using a meaning of the word "modularity" with which I am not familiar.

The workflow you promote (as far as I understand it) builds (parts of) Boost as an integral part of a user project that depends on (parts of) Boost. The lack of modularity (and more importantly: encapsulation) here is exactly the same lack of modularity I deplore in Boost itself: Rather than building, packaging, and testing the different components independently of one another (and then let them "consume" the prerequisites as pre-built entities), you promote building everything as a single monolithic entity. While I can see that some people would like the extra control that provides, I also see lots of problems with this approach. (And the fact that some of Boost is header-only is entirely irrelevant to my argument. If there is nothing to build there is nothing to build.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 24.06.2017 13:12, P F wrote:

...

On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost mailto:boost@lists.boost.org> wrote:

While I can see that some people would like the extra control that provides, I also see lots of problems with this approach. (And the fact that some of Boost is header-only is entirely irrelevant to my argument. If there is nothing to build there is nothing to build.)

Both school of thoughts are in disagreement about how to build their dependencies, and believe the other school of thought has lots of problems. Rather than boost try to pick just one(and alienate the other users), with cmake we can easily support both scenarios.

That's an illusion. My point is precisely that we can't "easily support" both, as it requires from all maintainers to understand all the build infrastructure. It's precisely the lack of encapsulation that causes this overhead. I'd be happy to include additional files in my library if it wasn't for the implied maintenance cost. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 26.06.2017 13:36, paul wrote:

...

It's precisely the lack of encapsulation that causes this overhead. I'd be happy to include additional files in my library if it wasn't for the implied maintenance cost. Yes, I would like the maintenance cost to be just adding source files to a

On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote: list somewhere. Of course, for header-only libraries its even easier.

Although, there are libraries like Boost.Python or Boost.Context that have more complicated build infrastructure, but the nice thing about cmake is that there is a much larger community to help with the maintenance cost rather than relying on a few Boost.Build gurus.

That's definitely true. But ultimately, it comes down to the maintainer or the library's own developer community. Whenever users try to build Boost.Python and run into issues, they are submitting issues to *our* tracker, and I hate having to tell them to go ask for help in a different community because I'm unable to help myself. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 26.06.2017 17:21, paul wrote:

...

...

...

It's precisely the lack of encapsulation that causes this overhead. I'd be happy to include additional files in my library if it wasn't for the implied maintenance cost. Yes, I would like the maintenance cost to be just adding source files to a

On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote: list somewhere. Of course, for header-only libraries its even easier.

Although, there are libraries like Boost.Python or Boost.Context that have more complicated build infrastructure, but the nice thing about cmake is that there is a much larger community to help with the maintenance cost rather than relying on a few Boost.Build gurus. That's definitely true. But ultimately, it comes down to the maintainer or the library's own developer community. Whenever users try to build Boost.Python and run into issues, they are submitting issues to *our*

On 26.06.2017 13:36, paul wrote: tracker, and I hate having to tell them to go ask for help in a different community because I'm unable to help myself. Not exactly. The user may have a build problem, but the likeliness that

On Mon, 2017-06-26 at 15:46 -0400, Stefan Seefeld wrote: they(or another user who is reading the issue) know enough cmake to contribute a fix is very much higher than them knowing enough bjam to provide a fix.

Oh, you are arguing about bjam vs. cmake. I wasn't. (I would agree that a well-known tool is better than an obscure one). My point is about having to maintain (and answer questions about) two infrastructures rather than one. I don't think it's realistic to assume that Boost as a whole will switch, at least not over a short period of time. If there was any lesson to be learned from passed changes to Boost, it's that such a move will take a very long time, if it's going to finish at all. Therefore I think it's much better to leave the decision to switch to individual project maintainers, as on that scale a change is much quicker to implement, if that's what the (project-) community decides to do. And for that to be possible individual projects need more autonomy, and the whole build infrastructure needs to be modular. Thus, what I propose is a little script that iterates over all boost components, invoking some well-defined entry-point on each, which *may* run `b2` locally, or it may invoke `cmake`. Of course there needs to be an agreed-upon protocol (what arguments that script needs to accept, what is the expected outcome of a build, i.e. where are the generated artefacts, etc.). I strongly believe that such an approach would be by far more realistic, efficient, and generate less friction and administrative overhead than a whole-sale move from bjam to cmake. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Stefan Seefeld wrote:

The workflow you promote...

Support. The word is support.

(as far as I understand it) builds (parts of) Boost as an integral part of a user project that depends on (parts of) Boost.

Exactly. This provides control over what exactly is built, the state of the entire project (the composition of dependency versions) is described by a single SHA, and it's easy to deploy.

The lack of modularity (and more importantly: encapsulation) here is exactly the same lack of modularity I deplore in Boost itself:

Fine. Don't use this workflow. The cmake files also support installation via CMake - that's number 3 in my list.

And the fact that some of Boost is header-only is entirely irrelevant to my argument. If there is nothing to build there is nothing to build.

There is something to build, it's just built as part of your project and is inlined into your code. If you build against Boost 1.53, you get Boost 1.53 embedded into your binary. If you build against 1.65 - 1.65. There is a way to encapsulate, it's called extern "C". Boost doesn't use it.

P F wrote:

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo

The library for Boost.System is just:

bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef )

This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list.

And this works for both `add_subdirectory` build and standalone builds.

Provided that the user has installed BCM, I presume? Because otherwise find_package(BCM) won't work.

P F wrote:

...

...

And this works for both `add_subdirectory` build and standalone builds.

Provided that the user has installed BCM, I presume? Because otherwise find_package(BCM) won't work.

Yes, of course, and considering that building standalone requires quite a bit of dependencies(six just for system) to be installed already, I don’t think one more dependency will be a problem in this scenario.

It's not a problem for standalone builds, where you do need to install and build dependencies, whether six or seven. For the add_subdirectory case, however, it changes the number of dependencies requiring installation from 0 to 1.

P F wrote:

No, you just do `include` instead of `add_subdirectory`, but it doesn’t require installation.

I'm not sure I understand. find_package(BCM) is unconditional in CMakeLists.txt, right? https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/libs/system/CMakeL... What 'include` do you do and where? Unrelated, why do you need `include(GNUInstallDirs)` here: https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/bcm/share/bcm/cmak... ?

On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:

P F wrote:

...

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo

The library for Boost.System is just:

bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef )

This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list.

Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep.

...

And this works for both `add_subdirectory` build and standalone builds.

Provided that the user has installed BCM, I presume? Because otherwise find_package(BCM) won't work.

On Jun 24, 2017, at 1:53 PM, Robert Ramey via Boost wrote:

On 6/24/17 11:42 AM, Edward Diener via Boost wrote:

...

On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:

...

P F wrote:

...

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo

The library for Boost.System is just:

bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef )

This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list. Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep.

I don't see that this is possible. Consider and example:

a) I have and application A which uses the boost::date_time library. b) But it doesn't serialize dates/times So it doesn't include the date_time/serialization header c) So application is not dependent upon the serialization library d) And it doesn't have to include build / maintenance overhead that including the serialization library would entail.

Later

a) I make application B which used the boost::date_time library b) Part of the app also serializes date_time data c) So it includes date_time/serialization header d) And must be linked with the serialization compiled libraries.

My point is that one cannot support the notion of dependencies between libraries outside of the context of a particular application.

That’s what conditionals can be used for. That is, you would build with `-DBOOST_DATE_TIME_WITH_SERIALIZATION=1` to build with serialization. However, boost’s directory structure doesn’t support this well, as you would need multiple include directories for the different options. A simpler option would be to make a different module. That is if the user would like serialization support for date time, they can do `add_subdirectory(boost_date_time_serialization)` or `find_package(boost_date_time_serialization)`

So dependencies will either have to specified/maintained by hand or one will need a tool which does something like

dependencies A.cpp -> dependent libraries for application A dependencies B.cpp -> dependent libraries for application B

That will just make things much more complicated to interpret. This is a why a separate module is probably preferred over optional dependencies.

On 6/24/17 1:18 PM, Edward Diener via Boost wrote:

On 6/24/2017 2:53 PM, Robert Ramey via Boost wrote:

...

On 6/24/17 11:42 AM, Edward Diener via Boost wrote:

...

dependencies A.cpp -> dependent libraries for application A dependencies B.cpp -> dependent libraries for application B

How is a library supposed to know what your application needs

Right it can't. That is my point. One cannot say that the date/time library dependent upon the serialization library just because it includes some of the serialization library headers. You can't say that any time the date/time is used the serialization library has to be included as well. You have to wait until you see the final application to know whether the part of date/time you actually used includes the serialization library. There seems to be an idea that one can build library dependencies automatically by recurrsively scanning the source code #include files. This examples shows why this cannot be done. Dependency outside of a particular application is undefined. ? That is not its responsibility. Doesn't CMake allow manipulation of what an

application needs at some higher level ? When I have used CMake to build LLVM/Clang it certainly allowed me to choose what I wanted for my particular build even though LLVM/CLang provide a whole slew of CMakeLists.txt files.

If we cannot setup CMake pretty easily for Boost

libraries so that the end-user can manipulate builds and tests for his needs our CMake setup will be worthless.

LOL - I'm sure we can do it manually. That's what I do. What we can't do is build date/time ahead of time before we know the application. This topic originally came up in the discussion of boost tools bcm? which automatically build a dependency tree. Robert Ramey

On 6/24/2017 2:53 PM, P F via Boost wrote:

...

On Jun 24, 2017, at 1:42 PM, Edward Diener via Boost wrote:

On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:

...

P F wrote:

...

https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo

The library for Boost.System is just:

bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef ) This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list.

Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep.

What do you mean generated on the fly? This is stored in each repo so that the user can add the libraries as submodules to their project.

I am saying that this should not have to be maintained manually. That is what I mean by "on the fly". How hard could it be to run some program or Python script which creates such a file for each library automatically ?

At release time, I believe, we would run `b2 cmake` and update the dependencies and version. Perhaps we could update the source list as well. Alternatively, we could glob the source file in cmake:

file(GLOB SOURCES src/*.cpp) bcm_boost_package(system VERSION 1.64 SOURCES ${SOURCES} DEPENDS assert config core predef )

This, in general, is considered bad practice, but might be better than waiting until release to update the source list. Perhaps, there is a better workflow for this.

On 25/06/2017 13:24, Peter Dimov via Boost wrote:

David Sankel wrote:

...

...

I've done a proof of concept for (2), which can be seen here:

https://github.com/pdimov/boost-cmake-demo-2

Thanks for contributing this Peter. Could you summarize the differences between your proof of concept and Niall's? I think one point of difference is the support for a CMake-based installation of libraries. Is there anything else?

Mine is more or less vanilla CMake, without separate targets for static/shared, and with installation support. I also don't list the header files, just the sources.

I don't see anything in Peter's example which couldn't be implemented in cmake 2.8? It's best practice cmake 2.8-3.0 no doubt, but cmake >= 3.5, I don't think so. I find the lack of clear separation of concerns problematic; the lack of cmake support for header only libraries unfortunate; far too much hard coding of volatile config goes on inside each library; I am unsure how this design would be easily adaptable to C++ Modules support; I don't find this approach particularly reusable by unknown third party cmake, though I can see why Peter will disagree with that. But one or two minor quibbles aside, as a cmake 2.8 design, it's great, and I'd far prefer this approach over what some others have suggested. Indeed its single biggest strength will be its strong familiarity to cmake users, the cmake gurus have done a great job banging the drum on designs like this over what came before. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

the lack of cmake support for header only libraries unfortunate;

Why do you say that? Of the six libraries, only System isn't header-only. Or do you mean that the optional header-only mode of System isn't supported?

Ok, my wording wasn't clear: "the lack of disambiguation to cmake of header, static and shared libraries unfortunate" Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

Ok, my wording wasn't clear: "the lack of disambiguation to cmake of header, static and shared libraries unfortunate"

Yes, as much as I like - in principle - the separate ::static/::shared targets, they are an "innovation" that raises certain questions to which I don't have satisfactory answers, so I felt that the initial cmake-ification should not innovate in this area.

They are definitely not an innovation. That target-based, fully declarative cmake programming was always the end goal of cmake 3. If you read the discussions on cmake-dev that was always clear. Now, I'll grant you that the choice to eliminate as much detail as possible from nonroot CMakeLists is unusual, and could be called an "innovation". However as anyone who has been dropped into mature corporate cmake knows, rootlevel reprogramming of child cmake is both very common and very well understood (search for all cmake stackoverflow posts by my former work colleague Fraser, he taught me most of my low level cmake tricks. Lovely guy too, he lurked here on boost-dev for many years, I don't believe he ever posted). Most would consider rootlevel reprogramming an anti-pattern to be avoided, and normally when you are overriding hard coded decisions in child cmake then it is. But if the child cmake never hard coded anything it didn't have to, suddenly it becomes a powerful form of abstraction and reusability. Well, powerful for cmake at least. But as I've said many times now, whomever ends up implementing this will decide, so much if not most of this discussion is moot and it always was. The real question is who will be implementing this and how far it will be taken within what time frame, and until the proposal lands at the SC and they take a decision, I'm not sure if further bike shedding here is worth anybody's time. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 6/25/17 1:49 PM, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

...

Yes, as much as I like - in principle - the separate ::static/::shared > targets, they are an "innovation" that raises certain questions to which > I don't have satisfactory answers, so I felt that the initial > cmake-ification should not innovate in this area.

They are definitely not an innovation.

It would have been an innovation for me, had I tried to produce such a design. My CMake knowledge only goes so far. When library A depends on B depends on C, and the end user links to A::static, B::shared, and C::header, I don't know how to write the CMakeLists of A, B, and C so that to make this work, and my - admittedly limited - understanding is that how to make this work is not yet common CMake knowledge.

FWIW - In my CMakeLists.txt for the serialization library one selects which variant he wants to build static or shared. The fact that I forgot how I did it speaks well for CMake. It couldn't have been too hard otherwise I wouldn't have done it.

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

...

I don't see anything in Peter's example which couldn't be implemented in cmake 2.8?

There’s `add_library(INTERFACE)` and `find_depdendency` which is not in cmake 2.8.

Ok, more poor wording by me. Peter's cmake makes no use of cmake 3 only design patterns that I could see. The old trick of implementing interface libraries in cmake 2.8 (and often necessary before cmake 3.5) was via empty static libraries, so you generate from cmake an empty source file and compile it into an empty static library, then propagate header dependencies etc. It's an easy function to write, and gets you 80% of proper cmake 3 interface libraries. find_dependency() isn't needed nor ought to be in any Boost cmake implementation for all the many good reasons I've already repeatedly listed ad nauseum by now. It's way overkill for Boost's needs and introduces significant added complexity and maintenance. If it's in any final design, I would consider such a design to be of poor quality not properly thought through. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/