On Apr 13, 2016, at 4:00 PM, Robert Ramey <ramey@rrsd.com> wrote:

On 4/13/16 1:08 PM, Stephen Kelly wrote:

...

boost@glenstark.net wrote:

...

what to do now?

http://thread.gmane.org/gmane.comp.lib.boost.build/27386

I found this to be interesting. I've made a CMake directory as part of the serialization library which I use for building the IDE files which aid in library build and testing. It can be found in the boost serialization module of boost. My motivation is to take a step in the direction whereby users desirous of using the serialization library could do so without having to use boost build. I envision a user being able to clone the serialization subdirectory, add it "somewhere" to his project and have it "imported”.

The CMakeLists.txt file should be in the top-level directory. Every library always provides the cmake file in the top-level directory. Plus, having in it the top-level directory allows it be easily installed using cget(ie `cget install boostorg/serialization`). Also, Boost.Hana and Boost.Compute provide a cmake build as well including pkg-config. Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake. I started writing a cmake(including testing using travis and appveyor) for Boost.Config here: https://github.com/pfultz2/config But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config. Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries). Cmake and pkg-config could still be provided for Boost.PP and maybe Boost.Predef(I am not sure if it depends on other libraries).

A big problem I found with CMake is that it has the same problem that all these tools have. It's not that obvious how to use it and takes a lot more investment of effort than one thinks it should. On the other hand, CMake is almost universal so the investment is amortized across all the code you import. So I resolved to plow through it. The result is my CMake cheatsheet described in the Boost Library Incubator website. After biting this bullet I've found CMake to be very useful especially since I like to you an IDE to develop an test code. Since the serializetion library is huge library with lots of tests and modules, it's impractical to use an IDE without such a tool such as CMake. I know I'm not using CMake to the very best advantage, and I'd like to see more information on making a canonical CMake file for a boost library such as boost serialization. Ideally, users would be able to make use of such a file and this would motivate library authors to include such a file with their libraries.

It would be nice if boost provided a cmake module(such as Boost.Cmake) which provided some utilities that would make building a boost library easier. It could provided utilities to help setup tests and install targets with pkg-config. Something like this: boost_package( PACKAGE mylib DESCRIPTION This is my library VERSION 1.0 DEPENDS filesystem thread SOURCES lib/*.cpp HEADERS include/*.hpp ) And then additional utilities for adding tests that support valgrind and compile fail tests. I do this already for my projects, so it would be nice if there was an official module that contained these utilities. I thought about proposing something like this for boost, but I figured it would get rejected since the majority of libraries in boost use Boost.Build.

Robert Ramey

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

On Apr 13, 2016, at 5:54 PM, Stephen Kelly <hello@steveire.com> wrote:

P F wrote:

...

Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.

I really recommend trying to generate cmake packages for the sake of users of boost. Once you have that, porting any boost library to use cmake is much easier - but it is a very different task and requires very different buy-in from people and is a much more significant change for the boost community.

What I proposed in that thread is for the benefit of boost users and is completely compatible with current boost community values (does not propose moving away from boost.build, which is a too-controversial topic).

Yet but it seems to be just putting lipstick on a pig. Boost should move to being able to be built in a simple and modular way and not require esoteric build tools, which will be a greater benefit to boost users.

...

I started writing a cmake(including testing using travis and appveyor) for Boost.Config here:

https://github.com/pfultz2/config

But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config.

I guess you're referring to

test/limits_test.cpp:#include <boost/core/lightweight_test.hpp>

in Boost.Config.

Yes, it also depends on type_traits in test/math_info.cpp as well.

The good news is that some of the cycles which I described previously are no longer present (due to http://lists.boost.org/Archives/boost/2015/01/219121.php I suppose). I made updated diagrams of this but haven't posted them yet.

But I was only interested in cycles from public headers, not tests.

...

Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries).

Let's party like it's 2013! \o/

I do remember discussion about this a couple years ago and as I recall, they didn’t go so well.

Be careful - you're about to get into a discussion of what a dependency is. :)

What I mean by dependency is what is needed to fully build, test, and install the library. I think that is pretty straightforward.

Thanks,

Steve.

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

On Apr 13, 2016, at 6:55 PM, Stephen Kelly <hello@steveire.com> wrote:

P F wrote:

...

...

What I proposed in that thread is for the benefit of boost users and is completely compatible with current boost community values (does not propose moving away from boost.build, which is a too-controversial topic).

Yes, but it seems to be just putting lipstick on a pig.

I definitely don't agree.

...

Boost should move to being able to be built in a simple and modular way and not require esoteric build tools, which will be a greater benefit to boost users.

Do you have data on how many users care about how boost is built? I'm curious. Which categories of boost users care?

If the users wants the latest boost(as system level package managers are usually behind) or the user is cross-compiling. Where I used to work, we always built boost because of cross-compiling. This usually required translating the cmake toolchain to the boost toolchain. Using cmake all the way through would make that easier.

If you port a library to cmake, will people using boost from the ubuntu package get the cmake package files?

I don’t know the details with that because I usually always use pkg-config over the cmake package files. I would assume so, since pkg-config files are available from ubuntu packages(not boost packages but other packages provide them).

Do you have some kind of plan? Some gradual switch of libraries, of packaging processes and tools and release processes and tools? Some point when building with cmake is the default, then the only way? How long will that take? Because only after that process is completed can a user depend on cmake package files being present, and that's when the boost+cmake *starts* to improve.

I see it happening on a per-library basis at first rather than as whole which is much more complicated. So, say we get rid of our cycles in Boost.Core and Boost.Config, then we can have libraries such as Boost.PP, Boost.Predef, Boost.Config, Boost.Core, and Boost.Hana building with cmake. Then libraries that depend on those can start to move to use cmake as well. A tool then can be used to retrieve and build the library and its dependencies(using rypple or cget). So then when the user wants Boost.Filesystem it can download and build the libraries needed just for Boost.Filesystem. Eventually the release process would move to a per-library release such as Boost.Filesystem 2.0 and then Boost.Filesystem 3.0 rather than everything versioned by the boost monolithic release. Then libraries that fail to move forward due to lack of maintainers or refusal to deal with cycles would then be left behind.

I really wonder what a viable plan along the lines you are thinking would look like.

In my mind, the only way to make the boost+cmake experience better for users in a finite time frame is to generate the package files with boost.build. That way users of package managers will get the cmake files and they will be useful.

It would make the experience better in the short-term.

...

...

Be careful - you're about to get into a discussion of what a dependency is. :)

What I mean by dependency is what is needed to fully build, test, and install the library. I think that is pretty straightforward.

I didn't mean a discussion with me :). I do think there's more relevant nuance to it than that, but let's not bother getting into it.

Thanks,

Steve.

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

On Apr 14, 2016, at 3:54 AM, Stephen Kelly <hello@steveire.com> wrote:

P F wrote:

...

If the users wants the latest boost(as system level package managers are usually behind) or the user is cross-compiling. Where I used to work, we always built boost because of cross-compiling.

Ok, so you're ignoring boost users who don't fit the same mold as you. You should make this more explicit in your plan. (I also think you should expand your mind a bit).

...

...

If you port a library to cmake, will people using boost from the ubuntu package get the cmake package files?

I don’t know the details with that because I usually always use pkg-config over the cmake package files.

Oh, you don't understand.

...

I would assume so, since pkg-config files are available from ubuntu packages(not boost packages but other packages provide them).

And where would the cmake files come from? How would they appear in the packages? They have to be generated, remember. Are you going to make cmake a hard requirement just to generate some files?

If a boost library is being built already with cmake, of course it will use cmake.

...

I see it happening on a per-library basis at first rather than as whole which is much more complicated.

I think you need a much more specific plan. I think you don't understand the problem yet.

...

So then when the user wants Boost.Filesystem it can download and build the libraries needed just for Boost.Filesystem.

I think you need to expand your mind beyond 'the user downloads the source and builds it'. You are missing entire worlds.

I think you are missing entire worlds as well. Everywhere I have worked, we always built boost from source.

...

Then libraries that fail to move forward due to lack of maintainers or refusal to deal with cycles would then be left behind.

And hitting conclusions like this is where you will hit community friction eventually I'm sure.

...

...

I really wonder what a viable plan along the lines you are thinking would look like.

In my mind, the only way to make the boost+cmake experience better for users in a finite time frame is to generate the package files with boost.build. That way users of package managers will get the cmake files and they will be useful.

It would make the experience better in the short-term.

I don't know what you mean here. My suggestion improves the experience 'in a short time frame'.

Anyway, you have made clear that only 'people building top of tree from source as part of building their own stuff' is the scope of what you're interested in. You have also made clear that you don't know what cmake packages are,

I never said that. I said I didnt know the details, and by details I meant the details of debian packaging. I do know what the cmake package files are.

and you have said you never use them. You don't seem to want to look outside your own bubble.

Given those points it's clear to me that you didn't understand my boost.build mailing list post.

Thanks,

Steve.

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

P F wrote:

What I mean by dependency is what is needed to fully build, test, and install the library. I think that is pretty straightforward.

While straightforward, that's not going to be very useful. Any library that uses Boost.Test for its unit tests will bring in all 39 of Test's dependencies. Given that most people are probably not intending to run the tests...

On 4/13/16 3:37 PM, P F wrote:

The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place. Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers. Every library always provides the cmake file in the top-level directory. Plus, having in it the top-level directory allows it be easily installed using cget(ie `cget install boostorg/serialization`).

Also, Boost.Hana and Boost.Compute provide a cmake build as well including pkg-config. I'll take a look at these.

Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.

I think that's what I'm proposing. I started writing a cmake(including testing using travis and appveyor) for Boost.Config here:

https://github.com/pfultz2/config

But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config. Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries). Cmake and pkg-config could still be provided for Boost.PP and maybe Boost.Predef(I am not sure if it depends on other libraries).

What I do is a) clone boost to my local machine b) build boost c) use CMake to build my project. I use cmake find to find the boost headers and libraries. d) now I have my project in CMake which works well the boost official library set. I can create the IDE project e) everything works great. f) If I'm working on the serialization library, I treat it as if it's a user library - building/testng with CMake. After I've got it working as I like, I run boost build just to make sure everything works correctly. Bood build has the advantage that I can run all the combinations of static/share, debug/release, etc - autmatically and use library_status to build a test matrix of all combinations. With the serialization library, it's not unusual to have 2000 cells in this matrix. FWIW - that's how I do it.

...

A big problem I found with CMake is that it has the same problem that all these tools have. It's not that obvious how to use it and takes a lot more investment of effort than one thinks it should. On the other hand, CMake is almost universal so the investment is amortized across all the code you import. So I resolved to plow through it. The result is my CMake cheatsheet described in the Boost Library Incubator website. After biting this bullet I've found CMake to be very useful especially since I like to you an IDE to develop an test code. Since the serializetion library is huge library with lots of tests and modules, it's impractical to use an IDE without such a tool such as CMake. I know I'm not using CMake to the very best advantage, and I'd like to see more information on making a canonical CMake file for a boost library such as boost serialization. Ideally, users would be able to make use of such a file and this would motivate library authors to include such a file wi

t h their libraries.

It would be nice if boost provided a cmake module(such as Boost.Cmake) which provided some utilities that would make building a boost library easier. It could provided utilities to help setup tests and install targets with pkg-config. Something like this:

boost_package( PACKAGE mylib DESCRIPTION This is my library VERSION 1.0 DEPENDS filesystem thread SOURCES lib/*.cpp HEADERS include/*.hpp )

And then additional utilities for adding tests that support valgrind and compile fail tests. I do this already for my projects, so it would be nice if there was an official module that contained these utilities. I thought about proposing something like this for boost, but I figured it would get rejected since the majority of libraries in boost use Boost.Build.

Hmmm - it seems that would be pretty easy to add by hand to the libraries I'm actually using. Robert Ramey

On 4/13/16 4:47 PM, P F wrote:

...

On Apr 13, 2016, at 6:00 PM, Robert Ramey <ramey@rrsd.com> wrote:

On 4/13/16 3:37 PM, P F wrote:

...

The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place.

The Fit library has the cmake at the top-level and it doesn’t have cmake files sprinkled all over the place.

...

Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers.

Breaking the convention makes it much more intrusive, since a fork is needed to put the cmake where its expected by other tools.

...

Every library always provides the cmake file in the top-level directory. Plus, having in it the top-level directory allows it be easily installed using cget(ie `cget install boostorg/serialization`).

...

Also, Boost.Hana and Boost.Compute provide a cmake build as well including pkg-config. I'll take a look at these.

Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.

I think that's what I'm proposing.

I started writing a cmake(including testing using travis and appveyor) for Boost.Config here:

...

https://github.com/pfultz2/config

But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config. Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries). Cmake and pkg-config could still be provided for Boost.PP and maybe Boost.Predef(I am not sure if it depends on other libraries).

What I do is

a) clone boost to my local machine b) build boost c) use CMake to build my project. I use cmake find to find the boost headers and libraries. d) now I have my project in CMake which works well the boost official library set. I can create the IDE project e) everything works great.

f) If I'm working on the serialization library, I treat it as if it's a user library - building/testng with CMake. After I've got it working as I like, I run boost build just to make sure everything works correctly. Bood build has the advantage that I can run all the combinations of static/share, debug/release, etc - autmatically and use library_status to build a test matrix of all combinations. With the serialization library, it's not unusual to have 2000 cells in this matrix.

FWIW - that's how I do it.

That may work for development, but its pretty horrible for users to do this to install the latest serialization library.

I'm not seeing a problem here. Plus, with the cycles, boost is still not tested correctly. Boost or the serialization library? Users who want to test he serialization library can do it this way. Those who want to test all of boost can't do it now with CMake anyway. Then there is the question of dependencies which we discussed some time ago without being able to arrive at a consensus. In summary, the usage of CMake is currently up to the individual library so it doesn't really need to follow other conventions. I generally agree that following convention is a good thing. But I'm not familiar with CMake to know that there actually is a convention nor what the rationale for such a convention might be.

...

...

...

A big problem I found with CMake is that it has the same problem that all these tools have. It's not that obvious how to use it and takes a lot more investment of effort than one thinks it should. On the other hand, CMake is almost universal so the investment is amortized across all the code you import. So I resolved to plow through it. The result is my CMake cheatsheet described in the Boost Library Incubator website. After biting this bullet I've found CMake to be very useful especially since I like to you an IDE to develop an test code. Since the serializetion library is huge library with lots of tests and modules, it's impractical to use an IDE without such a tool such as CMake. I know I'm not using CMake to the very best advantage, and I'd like to see more information on making a canonical CMake file for a boost library such as boost serialization. Ideally, users would be able to make use of such a file and this would motivate library authors to include such a

file wi t h their libraries.

It would be nice if boost provided a cmake module(such as Boost.Cmake) which provided some utilities that would make building a boost library easier. It could provided utilities to help setup tests and install targets with pkg-config. Something like this:

boost_package( PACKAGE mylib DESCRIPTION This is my library VERSION 1.0 DEPENDS filesystem thread SOURCES lib/*.cpp HEADERS include/*.hpp )

And then additional utilities for adding tests that support valgrind and compile fail tests. I do this already for my projects, so it would be nice if there was an official module that contained these utilities. I thought about proposing something like this for boost, but I figured it would get rejected since the majority of libraries in boost use Boost.Build.

Hmmm - it seems that would be pretty easy to add by hand to the libraries I'm actually using.

Yea, I usually do this by hand, the point is to avoided this copying and pasting.

So, we could make it a lot easier for users just by including the above boiler plate? In other words we wouldn't have to muck with boost build at all? I could buy that. Robert Ramey

On Wed, Apr 13, 2016 at 6:00 PM, Robert Ramey <ramey@rrsd.com> wrote:

On 4/13/16 3:37 PM, P F wrote:

...

The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place. Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers.

<http://www.boost.org/development/requirements.html#Organization> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/14/16 8:50 AM, Louis Dionne wrote:

Rene Rivera <grafikrobot <at> gmail.com> writes:

...

On Wed, Apr 13, 2016 at 6:00 PM, Robert Ramey <ramey <at> rrsd.com> wrote:

...

On 4/13/16 3:37 PM, P F wrote:

...

The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place. Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers.

<http://www.boost.org/development/requirements.html#Organization>

I think this recommendation is out of line with current practice. From my experience, the top level CMakeLists.txt file is almost always expected to appear at the root of the project. Out of the 25 most trending C++ projects this month on GitHub,

That may be true. But doing it in this way is very intrusive and conflicts with fundamental aspects of the boost way of doing things. But I always respect convention - except when I don't.

- 8 use CMake as a primary build tool - out of those, 7 have a CMakeLists.txt file at the root of the project

Actually I'm guessing that these projects support CMake as the only build tool. But that's just a guess

Unfortunately, there does not seem to be agreement about what build system to use (many use plain Makefiles), but among the ones that use CMake, agreement is on the CMakeLists.txt file being at the top level. Other notable projects that use CMake and include the CMakeLists.txt file at the root are Facebook's HHVM and Kitware's CMake itself. An example [1] on CMake's website also suggests doing this.

I don't agree with the work "Unfortunately". Actually I don't agree with the "Un". One of the key features of boost is that it tries to impose only the minimum requirements required to fulfill it's mission. Over the last 15 years we've seen huge evolution in build systems, documentation systems, social communication, etc. Our system has permitted this evolution to occur without upending all the components are making us spend huge amount of time in maintenance. In the places were to do work hard to get conformity, documentation, build systems, we get huge pushback from library authors who want to do things their own way. (e.g. DOxygen documentation).

Finally, FWIW, I think all the CMake-powered projects I've seen so far also put the top level CMakeLists.txt file at the root (but that is just my experience).

Another very, very, very bad idea. This conflicts in a fundamental way with the goal of modularization. It couples all the libraries together through the build system. This kind of coupling is the biggest single feature which makes it harder to support a growing set of Boost libraries.

Personnally, I will need something more authoritative than the requirement page you link above to be convinced of putting the CMakeLists.txt file in another place than the root of the project.

LOL - Boost is pretty easy - you pretty much have the right do whatever isn't specifically prohibited - even if it's a bad idea. What you don't have the right to do is to put something in the boost root or in some other library just to implement some preference in your own library. Robert Ramey

Regards, Louis Dionne

[1]: https://cmake.org/examples/

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

Robert Ramey <ramey <at> rrsd.com> writes:

On 4/14/16 8:50 AM, Louis Dionne wrote: [...]

...

I think this recommendation is out of line with current practice. From my experience, the top level CMakeLists.txt file is almost always expected to appear at the root of the project. Out of the 25 most trending C++ projects this month on GitHub,

That may be true. But doing it in this way is very intrusive and conflicts with fundamental aspects of the boost way of doing things. But I always respect convention - except when I don't.

When you don't is when problems arise.

[...]

...

Finally, FWIW, I think all the CMake-powered projects I've seen so far also put the top level CMakeLists.txt file at the root (but that is just my experience).

Another very, very, very bad idea. This conflicts in a fundamental way with the goal of modularization. It couples all the libraries together through the build system. This kind of coupling is the biggest single feature which makes it harder to support a growing set of Boost libraries.

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt. Regards, Louis

On Thursday, April 14, 2016 at 12:37:47 PM UTC-5, Rene Rivera wrote:

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldio...@gmail.com <javascript:>> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines

recommend

...

that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

Of course, Boost.Hana and Boost.Compute both put the cmake in the top-level so there is no tooling or infrastructure that is broken because of it. Even more so, tooling and infrastructure can be broken by following boost requirements for organization. So it would be best for boost to reconsider its organization requirements in this regard.

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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

On 2016-04-14 22:00, Edward Diener wrote:

On 4/14/2016 1:37 PM, Rene Rivera wrote:

...

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldionne.2@gmail.com> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

Ideally could not one have a CMakeLists.txt file wherever there is currently a jamfile ? In the library's 'build' directory to build a non-header only library, in the library's 'doc' directory to build the docs, in the library's 'test' directory to run the tests etc.

Yes, that is possible and what should be done according to the current guidelines. It's just not how it's typically done in other projects that use cmake.

My personal problem with CMake is, while the language to use it is more understandable for me than 'jam', its doc is just as hard for me to understand as Boost Build if not even harder <g>. Mastering yet another build system which is documented mainly for those who already know what it is about is not my idea of programming fun.

Unlike Boost.Build, cmake has built in commands 'cmake --help*' which at least make it easier to use when you know what you're doing.

On 2016-04-15 00:23, Bjørn Roald wrote:

On 14 Apr 2016, at 23:17, Andrey Semashev <andrey.semashev@gmail.com> wrote:

...

Unlike Boost.Build, cmake has built in commands 'cmake --help*' which at least make it easier to use when you know what you're doing.

have you tried to type b2 —help ?

I did, and it doesn't give anything close to what cmake gives.

On 2016-04-15 00:32, Rene Rivera wrote:

On Thu, Apr 14, 2016 at 4:30 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

...

On 2016-04-15 00:23, Bjørn Roald wrote:

...

On 14 Apr 2016, at 23:17, Andrey Semashev <andrey.semashev@gmail.com> wrote:

...

Unlike Boost.Build, cmake has built in commands 'cmake --help*' which at least make it easier to use when you know what you're doing.

have you tried to type b2 —help ?

I did, and it doesn't give anything close to what cmake gives.

Improvements welcome < https://github.com/boostorg/boost/blob/master/Jamroot#L10>.

Well, to offer improvements I should at least decently know Boost.Build, which I don't.

On 2016-04-15 00:34, Steven Watanabe wrote:

AMDG

On 04/14/2016 03:17 PM, Andrey Semashev wrote:

...

Unlike Boost.Build, cmake has built in commands 'cmake --help*' which at least make it easier to use when you know what you're doing.

Er, Boost.Build also has a --help option.

$ b2 --help zlib Module 'zlib':

Supports the zlib library

After 'using zlib', the following targets are available:

/zlib//zlib -- The zlib library

Module 'zlib' rules:

Use --help zlib.<rule-name> to get more information.

* init: Initializes the zlib library.

...found 1 target...

Hmm, I didn't know --help had further parameters, it doesn't follow from this description given in 'b2 --help': --help This message. Is there a way to see all modules? Rules? Properties? Something similar to 'cmake --help-commands/--help-variables/--help-command-list/--help-variable-list'?

On 2016-04-15 01:49, Steven Watanabe wrote:

AMDG

On 04/14/2016 04:25 PM, Andrey Semashev wrote:

...

Hmm, I didn't know --help had further parameters, it doesn't follow from this description given in 'b2 --help':

--help This message.

--help alone shows the project specific help from the Jamfile.

...

Is there a way to see all modules?

--help-internal lists all modules and describes the additional argument for --help.

* --help-internal Boost.Build implementation details. That description does look discouraging. Strange to look for help on Boost.Build interface in the implementation details. Perhaps --help could be documented to mention the argument as well, and --help-internal could be described as, well, not so internal?

...

Rules?

Only per module.

...

Properties?

Nope. I'm not sure that properties had been developed yet when the help system was written.

Ok, thank you.

On 4/14/2016 5:51 PM, Paul Fultz II wrote:

On Thursday, April 14, 2016 at 4:18:07 PM UTC-5, Andrey Semashev wrote:

...

On 2016-04-14 22:00, Edward Diener wrote:

...

On 4/14/2016 1:37 PM, Rene Rivera wrote:

...

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldio...@gmail.com <javascript:>> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

Ideally could not one have a CMakeLists.txt file wherever there is currently a jamfile ? In the library's 'build' directory to build a non-header only library, in the library's 'doc' directory to build the docs, in the library's 'test' directory to run the tests etc.

Yes, that is possible and what should be done according to the current guidelines. It's just not how it's typically done in other projects that use cmake.

The cmake files could be separated out to different directories, however there needs to be a top-level cmake to bring all of them together. This is because cmake is more of a configuration system rather than just a build system. So it can generate files for any build systems, Makefiles, Visual Studio. Technically, it could generate build files for boost, however, its not supported. So first you create and configure a build directory:

mkdir build cd build cmake ..

Then you can invoke the build through "targets". So if you want to build the tests you might build the 'check' target:

cmake --build . --target check

This is different than Boost.Build where you just cd into a directory and start building. This is why a top-level cmake file is important. The cmake file can be easily split across multiple cmake files if the library author wants, but there needs to be one at the top-level to glue them all together.

That's fair enough as long as one can "build" different parts of the library, with different options, separately.

Hello, I am new to this list, so let me start by greeting everyone. :) I would like to add something to this CMake discussion. I have a project "histogram" that I am currently preparing for the Boost Incubator. I am using the standard directory structure prescribed for Boost, and I use CMake for the build. There is only one CMakeLists.txt in the build directory. It is true that there is usually a top-level CMakeLists.txt, but it does not have to be there. I build like this cd /path/to/build cmake /path/to/project/build make ...where /path/to/project is the top-level directory of the project. In the CMakeLists.txt in /path/to/project/build, I use a relative path to locate the source files. add_executable(some_lib ../src/some_lib.cpp) etc. Best regards, Hans Dembinski On 4/14/16 7:11 PM, Robert Ramey wrote:

On 4/14/16 2:51 PM, Paul Fultz II wrote:

...

The cmake files could be separated out to different directories, however there needs to be a top-level cmake to bring all of them together.

I don't think this is true. I never do it.

Robert Ramey

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

This sounds similar if not identical to the advice I give in the Boost Library Incubator. I came to that advice after spending a lot of time investigating and experimenting with all the build tool options. I found them all too complex, too fragile, and not well documentated. Of course I trolled the net looking for information and advice as well. I came to my advice as the most expedient, simplest way to help other users test your library with the minimum of fuss for all involved. That was my goal and I think I achieved it. I try to follow everything on the boost incubator website, that's

Note that I didn't try to solve the "problem" of finding a replacement for boost build.

Having said this and participated in this discussion, I'm now inclined to update my advice on this topic so that the method I propose will be closer to the more common way of using CMake. I think I can do this now while still avoiding decent into CMake arcana. Of course it still won't meet the standards of CMake gurus, but they're not addressing my problem. I hope this is not a misunderstanding. I wrote my first message to agree with you that it is not weird or very awkward to have just one CMakeLists.txt in the build directory, even if it is a bit non-standard. I can't say much about the more complex arguments brought forward in

probably why you find your advice reflected in what I am doing. :) The reviewer's time is a sparse resource, so it makes sense to bring new people up to speed with the Boost Incubator and the guidelines published on that site. I find that quite useful. this thread.

Good luck with your submission. Thank you. :) I am still writing documentation, but I expect to finish soon.

Hans Dembinski

On 4/14/2016 5:17 PM, Andrey Semashev wrote:

On 2016-04-14 22:00, Edward Diener wrote:

...

On 4/14/2016 1:37 PM, Rene Rivera wrote:

...

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldionne.2@gmail.com> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

Ideally could not one have a CMakeLists.txt file wherever there is currently a jamfile ? In the library's 'build' directory to build a non-header only library, in the library's 'doc' directory to build the docs, in the library's 'test' directory to run the tests etc.

Yes, that is possible and what should be done according to the current guidelines. It's just not how it's typically done in other projects that use cmake.

That appears to be a minus for CMake. The build of a library is in my mind the summation of the build of its separate parts. Being able to build each part of a library ( the library itself, documentation, tests, examples etc etc. ) separately must be more flexible than having to build every part as a whole. In that respect Boost.Build has got it right IMO.

...

My personal problem with CMake is, while the language to use it is more understandable for me than 'jam', its doc is just as hard for me to understand as Boost Build if not even harder <g>. Mastering yet another build system which is documented mainly for those who already know what it is about is not my idea of programming fun.

Unlike Boost.Build, cmake has built in commands 'cmake --help*' which at least make it easier to use when you know what you're doing.

Boost Build also has a --help option. I do not think a --help option is sufficient for explaining how something works. I look at the CMake docs and there is no introduction, no overview, no attempt to explain how the different parts of the tool relate to each other. While the docs for the individual pieces of CMake have good explanations I really have to dig around to understand what I have and how I might want to use it, and I just don't have that patience. I hate the attitude of programming documentation that the reader should work hard to figure out basic things for himself because the documenter is just too lazy to explain those things in a reasonable clear way.

On 4/14/16 4:02 PM, Andrey Semashev wrote:

I think you misunderstood me. You can build sources, docs and tests separately. You can place CMakeLists.txt at the places where Jamfiles currently are. Each of these CMakeLists.txt would declare their own project and could be independent from others.

However, the common practice is a bit different. There is typically a single root CMakeLists.txt, which defines a project and then includes a number of nested CMakeLists.txt. The nested CMakeLists.txt may or may not define their projects, that doesn't really matter if you invoke cmake with the root CMakeLists.txt because you're generating makefiles for the whole tree in this case. You can also build targets selectively in this case.

My understanding is quite different. In each directory one has a CMakeLists.txt file. This would closely correspond to current boost practice. In addition in the parent directory one creates a CMakeLists.txt directory. It's primary function is to factor common CMake commands corresponding to the child directories. It includes a statement add_directory(<child directory name>) for each subdirectory. Then when you CMake the parent all the children are "CMaked" after having processed the common code in the parent. As it stands this makes sense. But if you include common CMake commands in the parent you won't be able to run CMake on the subdirectories. So if you want to that, just refrain from factoring common code in the parent directory CMake. I believe that CMake has an "include" facility so you could have it both ways - start from the parent or the children. CMake has a few issues. The documentation is very extensive - but really consists of just a reference to the CMake functions one can call. There is no overall sense of how the whole thing is supposed to work. There is a lot of information on stack overflow, etc to fill this gap. But most find a way that works and presume that everyone does it that way. Truth is there is not "canonical" way to do it - but everyone thinks there is and that they know what it is. Very confusing. I spent a lot of time studying the system in order to make my "CMake for dummies" cheat sheet which I included in the Boost Library Incubator. I described the simplest system which would work for a simple boost library - header only. My goal was simplicity. If I had nothing else to do I would expand upon it. But I don't so I can't Robert Ramey

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

Paul Fultz II wrote:

Because Cmake creates build artefacts when it runs, its best practice to create a separate build directory to run cmake. This avoids build artefacts from overwriting source files, and it makes it easier to clear out the build directory(necessary sometimes). To support multiple toolchains, I need to configure a build directory for each toolchain:

mkdir build-4.6 && cd build-4.6 && CXX=g++-4.6 cmake .. && cd .. mkdir build-4.7 && cd build-4.7 && CXX=g++-4.7 cmake .. && cd .. mkdir build-4.8 && cd build-4.8 && CXX=g++-4.8 cmake .. && cd .. mkdir build-4.9 && cd build-4.9 && CXX=g++-4.9 cmake .. && cd .. mkdir build-clang && cd build-clang && CXX=clang++ cmake .. && cd ..

Then if I want to build the tests for each toolchain, I need to build each directory:

ls -1 build-* | xargs -n1 cmake --target check --build

Boost.Build's build directory by convention is relative to Jamroot, not to the current directory or to the Jamfile, so it doesn't have this problem. And a CMake-based Boost should probably also put its build directories outside the library root by default.

On Friday, April 15, 2016 at 1:11:03 PM UTC-5, Peter Dimov wrote:

Paul Fultz II wrote:

...

Because Cmake creates build artefacts when it runs, its best practice to create a separate build directory to run cmake. This avoids build artefacts from overwriting source files, and it makes it easier to clear out the build directory(necessary sometimes). To support multiple toolchains, I need to configure a build directory for each toolchain:

mkdir build-4.6 && cd build-4.6 && CXX=g++-4.6 cmake .. && cd .. mkdir build-4.7 && cd build-4.7 && CXX=g++-4.7 cmake .. && cd .. mkdir build-4.8 && cd build-4.8 && CXX=g++-4.8 cmake .. && cd .. mkdir build-4.9 && cd build-4.9 && CXX=g++-4.9 cmake .. && cd .. mkdir build-clang && cd build-clang && CXX=clang++ cmake .. && cd ..

Then if I want to build the tests for each toolchain, I need to build each directory:

ls -1 build-* | xargs -n1 cmake --target check --build

Boost.Build's build directory by convention is relative to Jamroot, not to the current directory or to the Jamfile, so it doesn't have this problem.

Yes and CMake doesn't traverse up the directory looking for a root cmake file.

And a CMake-based Boost should probably also put its build directories outside the library root by default.

And this is entirely decided how the user decides to invoke cmake, as cmake will always configure build artefacts in the current directory. So if the user in the root directory, the user could do this: cmake test/ cmake --build test --target check This will build in the root directory, and there is nothing in cmake to prevent this ultimately. Fortunately, this is considered bad practice and no one ever builds libraries with cmake this way unless your name happens to be Robert Ramey.

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

On Friday, April 15, 2016 at 1:33:10 PM UTC-5, Robert Ramey wrote:

On 4/15/16 10:13 AM, Paul Fultz II wrote:

...

On Thursday, April 14, 2016 at 8:47:45 PM UTC-5, Robert Ramey wrote:

...

On 4/14/16 4:02 PM, Andrey Semashev wrote:

...

I think you misunderstood me. You can build sources, docs and tests separately. You can place CMakeLists.txt at the places where Jamfiles currently are. Each of these CMakeLists.txt would declare their own project and could be independent from others.

However, the common practice is a bit different. There is typically a single root CMakeLists.txt, which defines a project and then includes

a

...

...

...

number of nested CMakeLists.txt. The nested CMakeLists.txt may or may not define their projects, that doesn't really matter if you invoke cmake with the root CMakeLists.txt because you're generating makefiles for the whole tree in this case. You can also build targets selectively in this case.

My understanding is quite different.

In each directory one has a CMakeLists.txt file. This would closely correspond to current boost practice.

In addition in the parent directory one creates a CMakeLists.txt directory. It's primary function is to factor common CMake commands corresponding to the child directories. It includes a statement add_directory(<child directory name>) for each subdirectory. Then when you CMake the parent all the children are "CMaked" after having processed the common code in the parent. As it stands this makes sense. But if you include common CMake commands in the parent you won't be able to run CMake on the subdirectories. So if you want to that, just refrain from factoring common code in the parent directory CMake. I believe that CMake has an "include" facility so you could have it both ways - start from the parent or the children.

Unifying common utilities is not the only reason to have a top-level directory. The other reason is so users don't have to create multiple build directories.

<snip>

Right

<snip>

So CMake and boost build ecourage CMake files in each subdirectory. Agreed?

The only question is whether or not a CMakeList.txt file must exist in the parent/library directory.

My answer is ... it depends.

If I want to just build part of the library - like the docs it's very convenient to just create a local CMake project (in a separate directory tree) from <library>/docs/boostbook.

And whats the difference between creating a local directory and running `cmake --build <some_dir> --target doc`?

Similarly, if I want to just build the library without testing, it's convenient to just create a local CMake project which does this.

And you should be able to: mkdir build && cd build cmake --build .

If you want test using this approach, you'll create a separate build of the library which would be redundant. But it's not the end of the world. I'm guessing that boost developers would not be uncomfortable with all this.

But why deal with redundant builds? If you create your cmake like other libraries, you wouldn't have this problem. I don't see any advantage to your way, only disadvantages.

Now boost users.

Moving to boost users - some might find it convenient to have a library level CMakeList.txt file which includes add-directory. It it included much else, it might break the ability to make part of the library. I doubt most boost developers would be happy with this.

Actually, the CMake vision is that normal users install a "Package" which doesn't do any testing at all. So they are not in this game.

What? Any packaging system should allow the ability to run the tests as well.

On the other hand, If a library level CMakeLists.txt were required and the subdirectory level CMakeLists.txt could not function independently of this, then a user would have to build / test all or nothing.

This is not true at all. You can tell cmake what targets you want to built. Furthermore, all targets that are not part of the library or application should use the `EXCLUDE_FROM_ALL` property. For example, building hana doesn't build any tests, only when I build the `check` target, which will build and run the tests. The same is true for llvm/clang. This convention is quite common not just for cmake projects, but for autoconf projects as well.

I've always wanted to require library users to run all the tests and post the results to a common place. CDash supposedly supports this, but has a number of issues.

To summarize, I believe that the only issue here is having a CMakeList.txt in the library root directory. And I don't think it's a huge issue in the scheme of things. My view would be that if someone want's to do it - OK - but I think they getting the benefit they think they are.

The benefits of following the conventions makes it familiar for people who use cmake and autoconf tools. No one would think that they would need to cd into a directory to build a target. Also, it makes it easier to integrate with other tools. For example, I can build and install hana with just `cget install boostorg/hana`. I can also run the tests as well before installing by using `cget install --test boostorg/hana`. The same works for Boost.Compute, however, this won't work for serialization(and won't ever).

Robert Ramey

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

On Friday, April 15, 2016 at 7:01:27 PM UTC-5, Robert Ramey wrote:

On 4/15/16 3:45 PM, Paul Fultz II wrote:

...

On Friday, April 15, 2016 at 1:33:10 PM UTC-5, Robert Ramey wrote:

...

On 4/15/16 10:13 AM, Paul Fultz II wrote:

...

...

If I want to just build part of the library - like the docs it's very convenient to just create a local CMake project (in a separate directory tree) from <library>/docs/boostbook.

And whats the difference between creating a local directory and running `cmake --build <some_dir> --target doc`?

right - no difference. So you don't need the CMakeList.txt in the library root directory. That's my whole point.

...

...

Similarly, if I want to just build the library without testing, it's convenient to just create a local CMake project which does this.

And you should be able to:

mkdir build && cd build cmake --build .

right - no difference. So you don't need the CMakeList.txt in the library root directory. That's my whole point.

...

...

If you want test using this approach, you'll create a separate build of the library which would be redundant. But it's not the end of the world. I'm guessing that boost

developers

...

...

would not be uncomfortable with all this.

But why deal with redundant builds? If you create your cmake like other libraries, you wouldn't have this problem. I don't see any advantage to your way, only disadvantages.

I don't see any difference.

Redundant builds is a big difference.

The standard CMake way has a CMakelists.txt in each subdir

This is common but not necessary. Zlib doesn't put a cmake in each directory, neither does the Fit library.

...

...

Now boost users.

Moving to boost users - some might find it convenient to have a library level CMakeList.txt file which includes add-directory. It it included much else, it might break the ability to make part of the library. I doubt most boost developers would be happy with this.

Actually, the CMake vision is that normal users install a "Package" which doesn't do any testing at all. So they are not in this game.

What? Any packaging system should allow the ability to run the tests as well.

Hmmm - then wouldn't have to presume that all the boost libraries that the libraries and tests that the library depends upon would have to be included? So then one would have to couple all the libraries together via some convention. Wouldn't that suggest we have to address the problem of dependencies which are different depending upon whether one is just building the library or building an testing the library or building a particular application which uses the library?

Yes, of course, it will need to track test dependencies separate from the build dependencies. Cget already does that, I don't see that as problematic.

...

...

On the other hand, If a library level CMakeLists.txt were required and the subdirectory level CMakeLists.txt could not function independently of this, then a user would have to build / test all or nothing.

This is not true at all. You can tell cmake what targets you want to built.

Actually I wasn't really aware of this. If that's true, then there is really no difference. In any case you have to have CMakeLists.txt in each subdirectory. Regardless of whether you use your --build syntax or cd to the subdirectory and invoke CMake you'll get the same result.

Except as a user I would need to figure out the folder structure of your library before building, instead of invoking the standard `all` or `install` target.

The only time one needs the library root is when one want's to build all the targets.

...

Furthermore, all targets that are not part of the library or application should use the `EXCLUDE_FROM_ALL` property. For example, building hana doesn't build any tests, only when I build the `check` target, which will build and run the tests. The same is true for llvm/clang. This convention is quite common not just for cmake projects, but for autoconf projects as well.

Arrrrggggghhhh

...

...

I've always wanted to require library users to run all the tests and post

the

...

...

results to a common place. CDash supposedly supports this, but has a number of issues.

To summarize, I believe that the only issue here is having a CMakeList.txt in the library root directory. And I don't think it's a huge issue in the scheme of things. My view would be that if someone want's to do it - OK - but I think they getting the benefit they think they are.

The benefits of following the conventions makes it familiar for people who use cmake and autoconf tools. No one would think that they would need to cd into a directory to build a target.

This would not apply to boost build users.

Which is very few users of boost, as most boost users use some form of autotools, cmake, make, visual studio, etc.

...

Also, it makes it easier to integrate with other tools. For example, I can build and install hana with just `cget install boostorg/hana`. I can also run the tests as well before installing by using `cget install --test boostorg/hana`. The same works for Boost.Compute,

...

however, this won't work for serialization(and won't ever).

Hmmmm - why not?

Because it doesn't have a CMakeLists.txt in the root directory.

Robert Ramey

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

On April 16, 2016 12:59:18 AM EDT, Robert Ramey <ramey@rrsd.com> wrote:

...

Yes, of course, it will need to track test dependencies separate from the build dependencies. Cget already does that, I don't see that as problematic.

I think you should think about it more.

Paul's points are that cget presumes a top level CMakeLists.txt and that it can handle dependencies. Given those conditions, he claims that test dependencies can be handled. If you think otherwise, it would be helpful to point out what you think will fail.

...

...

...

however, this won't work for serialization(and won't ever).

Hmmmm - why not?

Because it doesn't have a CMakeLists.txt in the root directory.

LOL - well it wouldn't be a big deal to add a CMakeLists.txt file with 3 add_directory statments in it. And I really wouldn't object to it if I were to become convinced that it had a real benefit.

CMake-related tooling assumes a top-level list file. Deviating from that either breaks tools or requires adding rarely needed options to deal with an unconventional layout. IME, CMake is both helpful and frustrating. As Paul noted, supporting multiple platforms is managed via multiple out-of-source-tree build directories. Besides keeping platform-specific artifacts separate, that has the advantage of allowing the use of local disk even when the source tree is on the network. It also has the disadvantage of having to dance around in multiple trees to find source files and build artifacts, and the inability to build from anywhere within the source or build trees. (I could list more, but that's enough for my purpose.) To address these and other issues, I've found it necessary to use a script to manage CMake. That script generates a top-level CMakeLists.txt, if there isn't one, creates a build directory appropriate for the host platform and selected compiler, cd's to that directory, and issues the appropriate cmake command. The script also finds its way between the two trees, using breadcrumbs, which allows issuing the build command from anywhere in the two trees. My point is that a top-level list file can be generated, and choosing what and how to build and run need not always conform to CMake conventions. However, doing so means one needs additional scripting and, unfortunately, CMake-related tools know nothing of the added scripts. Paul and Louis are arguing in favor not only of convention, to avoid user surprises, but of enabling cget, Travis, Appveyor, and other tools that will help Boost generally, or library authors/maintainers individually. ___ Rob (Sent from my portable computation engine)

On 4/16/2016 10:37 AM, Peter Dimov wrote:

Rob Stewart wrote:

...

Paul and Louis are arguing in favor not only of convention, to avoid user surprises, but of enabling cget, Travis, Appveyor, and other tools that will help Boost generally, or library authors/maintainers individually.

While I agree 120% with Rene's post

http://lists.boost.org/Archives/boost/2015/06/223027.php

I wouldn't be opposed to libraries having a top-level .travis.yml, appveyor.yml and CMakeLists.txt, because, well, the alternative is not supporting Travis/Appveyor/generic CMake tooling.

After taking a look at Travis and Appveyor, I now better understand Stefan Seefeld's desire to support compilation of Boost.Python against a system-installed Boost, because this is the environment that's easy to achieve on Travis (Boost 1.55 available via apt-get.)

For people who prefer to match our current testing, where the develop library is tested against its develop dependencies, Travis isn't very suitable. It checks out the library repo but knows nothing about the superproject, so basically one has to re-download the library again using the proper structure.

If all libraries had CMakeLists.txt (and no cyclic test dependencies), cget --test could do it. Otherwise, when I at some point get some free time and implement my plan for the next iteration of bpm, it would be able to do it as well.

Travis and Appveyor are no match for our test matrix because they only have "mainstream" compilers which I either have, or which correlate strongly with those I have, but the approach itself is interesting as something that we may need to think how to duplicate for our purposes. That is, our test infrastructure could activate on commit as Travis does.

On the other hand, there's also the fact that a commit in a dependency may break a library without it changing.

Are you envisioning a test infrastructure "activating" as meaning that it will only test the library for which the commit is made ?

On 4/16/2016 11:41 AM, Peter Dimov wrote:

Edward Diener wrote:

...

Are you envisioning a test infrastructure "activating" as meaning that it will only test the library for which the commit is made ?

Yes, that's also how Travis and Appveyor work. The upside is that libraries that are actively being worked on receive prompt test attention. The downside is that dependents aren't tested if they don't change. So we'll probably need some sort of a hybrid approach.

If bpm can get "fine" enough ( maybe it already is ? ) we should be able to trigger tests in such an infrastructure based on dependencies, so that a commit will not only test the library to which the commit was made but also those libraries that depend on that library, and it needs to work recursively. Of course we would need to understand that a library's headers may depend on different libraries than a library's tests depend on etc. That's the ideal case but a good testing infrastructure can certainly aim for it.

On Sat, Apr 16, 2016 at 11:50 AM, Peter Dimov <lists@pdimov.com> wrote:

Edward Diener wrote:

If bpm can get "fine" enough ( maybe it already is ? ) we should be able

...

to trigger tests in such an infrastructure based on dependencies, so that a commit will not only test the library to which the commit was made but also those libraries that depend on that library, and it needs to work recursively.

The problem here is that in order to determine which libraries depend on the changed library X the tool (boostdep or bpm) needs to look at the source of the potentially dependent libraries in order to see if they include a header from X. And for that it needs a full checkout - which is one of the things we're trying to avoid.

The alternative is maintaining a dependency graph separately, by a cron job, for instance.

I don't have a suitable 24/7 machine or I'd setup a continuously running Boostdep - having an up-to-date dependency report somewhere is always a plus even for humans.

Or, we could generate a dependency graph as part of the release procedure and use the one from the last release.

We could generate that as part of the CI building we already do. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/14/16 12:00 PM, Edward Diener wrote:

On 4/14/2016 1:37 PM, Rene Rivera wrote:

...

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldionne.2@gmail.com> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt, while I argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

Ideally could not one have a CMakeLists.txt file wherever there is currently a jamfile ? In the library's 'build' directory to build a non-header only library, in the library's 'doc' directory to build the docs, in the library's 'test' directory to run the tests etc.

I don't know CMake but I assume it must be capable of having multiple CMakeLists.txt files for a library, or that a library's top-level CMakeLists.txt can refer to the individual CMakeLists.txt files in order to "build" all the library's components. If it is not capable of such stuff it certainly isn't usable by Boost.

Actually I believe that that is the way CMake is generally used. When I got CMake working I put it all in one file in order to replicate the pattern I'm used to with boost build. Now I'm beginning to think this might have been a mistake. I wondering if we shouldn't have used: <library name> include *.hpp src *.cpp Jamfile.v2 CMakelist.txt doc html boostbook CMakeList.txt to convert boost book to html quikbook CMakeList.txt to convert quikbook to html ... test Jamfile.v2 CMakelist.txt *.cpp *.pp ... Note that not all libraries would have all components. This has the appeal of being regular.

My personal problem with CMake is, while the language to use it is more understandable for me than 'jam', its doc is just as hard for me to understand as Boost Build if not even harder <g>. Mastering yet another build system which is documented mainly for those who already know what it is about is not my idea of programming fun.

This is the plague of "modern tools" I spend more time working/configuring/etc the tools than I do actually writing source code. It's a very depressing situation and no tool is immune. Robert Ramey

On 4/14/16 4:31 PM, Peter Dimov wrote:

Robert Ramey wrote:

...

I wondering if we shouldn't have used:

<library name> ... src *.cpp Jamfile.v2 CMakelist.txt

Intuitively, this makes sense and I've wondered the same, before I realized that with our current structure, when you issue the command

b2 build

from the library root, it builds the library. (And of course

b2 test

tests it.)

b2 src

doesn't have quite the same ring to it.

This is very odd. It has never occurred to me to do such a thing and in fact I would never have guessed that it's possible. I always do: cd build b2 cd test b2 etc. As it turns out, one could do the exact same thing with CMake Robert Ramey

On 14 April 2016 at 18:37, Rene Rivera <grafikrobot@gmail.com> wrote:

On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldionne.2@gmail.com> wrote:

...

Don't overthink it. All I'm saying is that the Boost guidelines recommend that CMakeLists.txt should appear in $some_library/build/CMakeLists.txt,

while I

...

argue that current practice is to put it in $some_library/CMakeLists.txt.

Just to be clear. It's not a recommendation. It's a requirement.

There is a requirement that there be a $library/build/CMakeLists.txt, but that doesn't prevent $library/CMakeLists.txt from also existing.

Louis wrote:

I must admit having a hard time being imposed something like this, given that Boost does not support CMake at the moment. I understand the importance of satisfying the requirements for Boost.Build (and Hana satisfies them), because that is how the rest of Boost works. But I don't see why I should be imposed something w.r.t. CMake, since that is completely unrelated to the Boost infra.

The impression I get is that the repositories under boostorg are primarily intended to support the Boost release process. Until the Boost release process requires (or supports) CMake, it doesn't matter if the individual library repositories do not support CMake: i.e. it is still more important that they adhere to the guidelines. (You can substitute CMake in the preceding sentence with any other technology.) Which means that if you do want to support something like CMake for users of your library (or yourself) or do anything which involves putting files in your library's root directory (like CMakeLists.txt) that you would instead: - Use a separate repostiory (ldionne/hana instead of boostorg/hana) - Use a separate branch (not 'master' or 'develop') in this repository Glen -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-what-to-do-now-tp4685286p4685393.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.

Paul wrote:

This would be unfortunate, as it would make it a pain to use a lot of tools(cmake, travis, appveyor, etc) with boost libraries just because of an arbitrary rule 15 years ago.

Right. It would be better if the Boost guidelines were less restrictive. The approach I would prefer is: Instead of restricting the contents of the library repository root directory, restrict the contents of the '.boost' (or 'boost', or 'meta') directory. There should be sufficient specification in there to inform the Boost build and release process about the library. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-what-to-do-now-tp4685286p4685403.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 2016-04-16 01:46, Paul Fultz II wrote:

On Friday, April 15, 2016 at 4:17:11 PM UTC-5, Glen Fernandes wrote:

...

Paul wrote:

...

This would be unfortunate, as it would make it a pain to use a lot of tools(cmake, travis, appveyor, etc) with boost libraries just because of an arbitrary rule 15 years ago.

Right. It would be better if the Boost guidelines were less restrictive.

The approach I would prefer is: Instead of restricting the contents of the library repository root directory, restrict the contents of the '.boost' (or 'boost', or 'meta') directory. There should be sufficient specification in there to inform the Boost build and release process about the library.

I agree.

I'll remind where those requirements come from: http://thread.gmane.org/gmane.comp.lib.boost.devel/264776 http://lists.boost.org/Archives/boost/2015/06/223027.php The second link gives the rationale for having the restriction on the directory structure. Although I have my minor disagreements with the policy (not related to cmake), I can understand why Rene, as the maintainer for various Boost tools, is requesting a certain degree of conformance. Really, there's no problem with putting CMakeLists.txt into <library>/build.

Glen Fernandes <glen.fernandes <at> gmail.com> writes:

[...]

The approach I would prefer is: Instead of restricting the contents of the library repository root directory, restrict the contents of the '.boost' (or 'boost', or 'meta') directory. There should be sufficient specification in there to inform the Boost build and release process about the library.

+1 If we really want to go the modular way, I think it makes sense to reduce the coupling between the monolithic Boost release and the layout of individual libraries. Louis

Robert Ramey wrote:

Renee might have said that this is a requirement but he can't be correct here. The boost build/test process is tolerant of "other" files in the library directory. I know because I have a few of them. I have a separate directory for CMake stuff and another one for performance tests, some boost build/test utilities etc.

There is some misunderstanding then. As far as I know, it is a new requirement. The build system may be tolerant of them, but the idea that was communicated to the list was to require that all libraries root directories contain no other files besides those permitted by the guidelines. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-what-to-do-now-tp4685286p4685400.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Thu, Apr 14, 2016 at 11:08 AM, Robert Ramey <ramey@rrsd.com> wrote:

On 4/14/16 7:22 AM, Rene Rivera wrote:

...

On Wed, Apr 13, 2016 at 6:00 PM, Robert Ramey <ramey@rrsd.com> wrote:

On 4/13/16 3:37 PM, P F wrote:

...

...

The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place. Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers.

<http://www.boost.org/development/requirements.html#Organization>

LOL - can you believe that in 13 years (since the copyright date 2003) I've never seen this - or at least never remember seeing this?

I can believe it :-) It's some times easier some times to just copy what others are doing and looking up docs. Had I been around at the beginning and had perfect vision 15 years into the

future, I would have advocated for a structure <library name> build boost_build

Good idea.. But indeed 15 years late. doc

html boostbook markup

..

src ... test ... performance test ...

That's about what we have. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Apr 13, 2016, at 6:04 PM, Peter Dimov <lists@pdimov.com> wrote:

P F wrote:

...

I started writing a cmake(including testing using travis and appveyor) for Boost.Config here:

https://github.com/pfultz2/config

But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config.

Where does Config depend on Core? In limits_test.cpp?

Yes, here is a rough list of all the includes outside of config in the tests: $ grep -r "#include <boost/" . | grep -v boost/config | sort -u ./abi/abi_test.hpp:#include <boost/cstdint.hpp> ./config_info.cpp:#include <boost/version.hpp> ./cstdint_include_test.cpp:#include <boost/cstdint.hpp> // must be the only #include! ./cstdint_test.cpp:#include <boost/cstdint.hpp> ./cstdint_test.cpp:#include <boost/detail/lightweight_test.hpp> ./cstdint_test2.cpp:#include <boost/cstdint.hpp> ./cstdint_test2.cpp:#include <boost/detail/lightweight_test.hpp> ./has_tr1_array_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_array_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_bind_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_bind_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_complex_over_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_complex_over_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_complex_trig_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_complex_trig_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_function_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_function_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_hash_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_hash_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_mem_fn_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_mem_fn_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_random_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_random_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_ref_wrap_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_ref_wrap_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_regex_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_regex_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_result_of_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_result_of_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_shared_ptr_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_shared_ptr_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_tuple_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_tuple_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_type_traits_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_type_traits_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_unordered_map_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_unordered_map_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_unordered_set_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_unordered_set_pass.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_utility_fail.cpp:#include <boost/tr1/detail/config.hpp> ./has_tr1_utility_pass.cpp:#include <boost/tr1/detail/config.hpp> ./limits_test.cpp:#include <boost/core/lightweight_test.hpp> ./limits_test.cpp:#include <boost/detail/lightweight_main.hpp> ./limits_test.cpp:#include <boost/limits.hpp> ./math_info.cpp:#include <boost/limits.hpp> ./math_info.cpp:#include <boost/type_traits/alignment_of.hpp> Also, as you see math_info.cpp needs Boost.TypeTraits as well.

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

On Apr 13, 2016, at 7:14 PM, Peter Dimov <lists@pdimov.com> wrote:

P F wrote:

...

...

Where does Config depend on Core? In limits_test.cpp?

Yes, here is a rough list of all the includes outside of config in the tests: $ grep -r "#include <boost/" . | grep -v boost/config | sort -u ...

Most of those are Config's, except

...

./cstdint_test.cpp:#include <boost/detail/lightweight_test.hpp> ./cstdint_test2.cpp:#include <boost/detail/lightweight_test.hpp> ./limits_test.cpp:#include <boost/core/lightweight_test.hpp> ./limits_test.cpp:#include <boost/detail/lightweight_main.hpp> ./math_info.cpp:#include <boost/type_traits/alignment_of.hpp>

We haven't been looking at test dependencies, just at the include dependencies - they were enough of a mess but are better now. Source dependencies are a superset of those, and test dependencies are the worst. Source dependencies only matter if you want to build the libraries (which means always, except for binary modular distributions) and test dependencies only matter if you want to run the tests (which means not very often.)

Yes, the test dependencies are less often, and its probably good idea to look at the source dependencies before the test dependencies, but I don’t think we can ignore the test dependencies forever.

Fixing Config's tests to not depend on anything would basically require reimplementing lightweight_test there, which might not be that bad in principle, but that will not matter much for the big picture unless all libraries drop Boost.Test in favor of something that does not depend on anything Boost.

Does lightweight_test depend on something else? If so, lightweight_test could be moved to a separate module. This way Boost.Config would depend on Boost.LightweightTest and Boost.Core would depend on Boost.Config and Boost.LightweightTest. With C++11, it is fairly easy to write a testing framework with no dependencies. I wrote the library Prove to handle testing: https://github.com/pfultz2/Prove Which is just a single header so its easy to copy. Plus, it doesn’t require macros to auto-resgister the tests so it makes it easier to do templated tests or data-driven tests. I don’t know if lightweight_test requires other dependencies because its trying to support pre-C++11. If so, it would be nice if boost provided a lightweight modern C++ testing framework that had no dependencies.

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

On Apr 14, 2016, at 6:01 AM, Peter Dimov <lists@pdimov.com> wrote:

P F wrote:

...

Does lightweight_test depend on something else? If so, lightweight_test could be moved to a separate module. This way Boost.Config would depend on Boost.LightweightTest and Boost.Core would depend on Boost.Config and Boost.LightweightTest.

lightweight_test depends on Config for BOOST_NO_EXCEPTIONS, used in BOOST_TEST_THROWS. I thought about moving it to Assert, which seems like a logical place for it, but Assert depends on Config for BOOST_LIKELY.

Since Boost.Config only uses it for BOOST_TEST, it easy enough to just write: #define BOOST_TEST(x) if (!(x)) { std::cout << “FAILED”; std::abort(); } However, Boost.Config's test still depends on type traits.

But, as I said, the main obstacle would be Boost.Test.

True, however, at least the core libraries of boost can be fully cycle-free. So newer libraries can be built using the core utilities without having to deal with cycles.

I'm not quite sure that eliminating cycles in test dependencies is worth its while. There is no actual cycle. Config's tests depend on Core, which depends on Config's headers, not its tests.

If boost ever wants to support the standard `make && make check && make install` with cmake then this will be a cycle.

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

On 13 April 2016 at 23:37, P F <pfultz2@yahoo.com> wrote:

Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.

CMake can be used in a myriad different ways, some arguably better than others. Not having a global view would just lead to everything being inconsistent and incompatible.

On Thursday, April 14, 2016 at 11:51:51 AM UTC-5, Edward Diener wrote:

On 4/14/2016 9:55 AM, Paul Fultz II wrote:

...

...

On Apr 14, 2016, at 8:31 AM, Paul Fultz II <pfu...@yahoo.com

...

...

...

On Apr 14, 2016, at 6:01 AM, Peter Dimov <li...@pdimov.com

<javascript:>> wrote:

...

...

P F wrote:

...

Does lightweight_test depend on something else? If so,

<javascript:>> wrote: lightweight_test could be moved to a separate module. This way Boost.Config would depend on Boost.LightweightTest and Boost.Core would depend on Boost.Config and Boost.LightweightTest.

...

...

...

lightweight_test depends on Config for BOOST_NO_EXCEPTIONS, used in

BOOST_TEST_THROWS. I thought about moving it to Assert, which seems like a logical place for it, but Assert depends on Config for BOOST_LIKELY.

Since Boost.Config only uses it for BOOST_TEST, it easy enough to just write:

#define BOOST_TEST(x) if (!(x)) { std::cout << “FAILED”; std::abort(); }

However, Boost.Config's test still depends on type traits.

Well actually Boost.Config could use Boost.TypeTraits when BOOST_NO_CXX11_STD_ALIGN is defined, otherwise it could use the standard type traits. This would at least get rid of the cycle on modern compilers.

I think that should be BOOST_NO_CXX11_HDR_TYPE_TRAITS rather than BOOST_NO_CXX11_STD_ALIGN.

Yes, even better. Thanks.

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

On Thursday, April 14, 2016 at 9:56:56 AM UTC-5, Peter Dimov wrote:

Paul Fultz II wrote:

...

If boost ever wants to support the standard `make && make check && make install` with cmake then this will be a cycle.

OK. Why is having a cycle unacceptable?

Ah, wait, I get it, you can't 'make install' before you 'make check', and you can't 'make check' before 'make install'-ing both libraries first.

Persuading people to support this will be... difficult. The standard answer is that the tools need to be made smarter.

Yep, and iOS doesn't handle facebook's scale.

bpm doesn't have a problem with cycles because it doesn't have a separate install step.

However, bpm can't remove or update a library either.

Your 'make check' step would need to be able to find the downloaded dependency in-place, without relying on it being 'make install'-ed first. So when you do cget boostorg/config, it would need to download Config, Core, Assert, Predef, Type Traits, and whatever else is required, then 'make check' at the download location using the downloaded libraries. Which is probably out of scope for cget, as it's generic and this workflow is boost-specific.

There would need to be a staging step first, and then the test can be run and then the libraries installed. However, this process is quite unconventional, and could be problematic for basic package management.

How does cget find the dependencies now by the way?

It sets up the cmake prefix path, and then dependencies can be found using either cmake package files, pkg-config, or find_library. Also, include directories are setup as well to search in ${CMAKE_PREFIX_PATH}/include. So for header only libraries, no extra search step is needed for dependencies. cget can auto install the dependecies as well. Currently, it grabs dependencies listed in a requirements.txt file, which it will do a `cget install` on everything listed there. Test dependencies can be distinguished as well, so they are only installed when doing something like `cget install --test boostorg/config`. In the future, it will support channels which will allow multiple versions, constraints and SAT solving to find the best version.

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

On Thursday, April 14, 2016 at 11:11:44 AM UTC-5, Peter Dimov wrote:

Paul Fultz II wrote:

...

...

bpm doesn't have a problem with cycles because it doesn't have a separate install step.

However, bpm can't remove or update a library either.

It can remove, actually. Updating is not required because it only targets a specific Boost release and does not version libraries separately.

How does it know what files are associated with which library? It seems more difficult to figure that out installing all the libraries together.

To remove a cycle without -f, you need to remove all libraries that participate in the cycle in a single step, otherwise it complains about not being able to remove a library that is still being depended on.

...

cget can auto install the dependecies as well.

Yes, that's what I was asking.

...

Currently, it grabs dependencies listed in a requirements.txt file, which it will do a `cget install` on everything listed there.

So you depend on the library maintaining up-to-date dependency information in requirements.txt? Is this file cget-specific, or is it some existing convention?

It is cget-specific. Channels will provide a non-intrusive way to get dependencies. Although, I don't think its unreasonable for a library to track its own dependencies.

...

Test dependencies can be distinguished as well, so they are only installed when doing something like `cget install --test boostorg/config`.

Yes, and then you need to decide f.ex. when removing Core do you allow it while Config is still there, because this would break Config's tests but they may not be needed anymore.

This is a good point. The test dependencies shouldn't be tracked as dependants when they are installed. This way when a test dependency is removed it won't remove the package that was used test with it.

The alternative is to track Config and "Config's tests" as two separate modules which immediately solves the cycle but has other drawbacks.

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

On Thursday, April 14, 2016 at 12:02:14 PM UTC-5, Peter Dimov wrote:

Paul Fultz II wrote:

...

How does [bpm] know what files are associated with which library? It seems more difficult to figure that out installing all the libraries together.

It cheats by assuming that library 'foo' is always in $BOOST_ROOT/libs/foo, so it just removes the whole directory.

Doesn't boost install into the standard ${PREFIX}/include and ${PREFIX}/lib directories? I don't understand how bpm will remove the headers and the libs that were installed for a module.

In principle, it could re-download the package and remove only the files it contains, or it could record the files somewhere so it would know what to remove. But for Boost specifically, this doesn't seem worth the bother, because libraries are indeed contained in their libs/ subdirectories.

cget uses symlinks.

...

Although, I don't think its unreasonable for a library to track its own dependencies.

It may be reasonable... but for a Boost library it's not going to be very reliable. Since Boost library maintainers nearly always work against a full checkout, libraries can acquire (and sometimes drop) dependencies via a one-line edit and it's very easy to forget to record this in a 'requirements' file.

Yes, but having a tool to retrieve these requirements could change the way libraries are tested. Instead they can be tested against just its dependencies using `cget build --test` instead of needing a full checkout.

bpm relies on dependency information generated by boostdep,

And that tool could be used to generate the channel needed for cget.

but I need to rework it to scan on its own. The additional problem here is that if you don't have the full checkout you don't know what module contains which header. At some point in the future #include <boost/foo/bar.hpp> may always mean the foo library, but we're not there yet and it's not clear if we'll ever be.

While it may not be necessary for tooling, that would be nice for developers to easily know where a header came from.

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

On 2016-04-14 21:30, Peter Dimov wrote:

Paul Fultz II wrote:

...

Doesn't boost install into the standard ${PREFIX}/include and ${PREFIX}/lib directories?

"b2 install" does, yes.

...

I don't understand how bpm will remove the headers and the libs that were installed for a module.

bpm (which is as of yet still a toy and is not being used) doesn't install into $PREFIX/include and $PREFIX/lib. The use case is that you choose a directory in which to put Boost and it downloads the libraries there. It doesn't have an install step that copies the headers and the libraries into a systemwide location.

That's more of a Windows workflow, where there is no systemwide location for libraries, so one just puts them wherever convenient; but given that most Linux distros already have their own Boost in /usr/include and /usr/lib, a typical case for installing by hand would be to use a newer release which one might also want to put not in /usr/{include,lib}.

I'll add that 'make install' is in fact considered a bad practice in Linux because there is typically no 'make uninstall' and you're on your own if you want to remove or upgrade the software. The preferred way is either package the software and use the package manager to install/remove/upgrade or install into a separate directory tree which can be removed completely when needed.

On 14 April 2016 at 22:36, Paul Fultz II <pfultz2@yahoo.com> wrote:

And a package manager will use the 'make install' to install the library.

With a system like dpkg, you just define a GNU Makefile that calls whatever build system the software you're packaging is using. All you need to do is put the files you want in a directory, then convert that directory to a .deb. Whether you want to use "make install" or anything else is up to you.

On Thursday, April 14, 2016 at 1:31:36 PM UTC-5, Peter Dimov wrote:

Paul Fultz II wrote:

...

Doesn't boost install into the standard ${PREFIX}/include and ${PREFIX}/lib directories?

"b2 install" does, yes.

...

I don't understand how bpm will remove the headers and the libs that were installed for a module.

bpm (which is as of yet still a toy and is not being used) doesn't install into $PREFIX/include and $PREFIX/lib. The use case is that you choose a directory in which to put Boost and it downloads the libraries there. It doesn't have an install step that copies the headers and the libraries into a systemwide location.

Thats what I though it did. So at the same time, it doesn't have a way to remove libraries after they have been installed. It gets a little more complicated keep track of which files goes to which library when they all install at the same time.

That's more of a Windows workflow, where there is no systemwide location for libraries, so one just puts them wherever convenient; but given that most Linux distros already have their own Boost in /usr/include and /usr/lib, a typical case for installing by hand would be to use a newer release which one might also want to put not in /usr/{include,lib}. So whether you download somewhere and copy to $PREFIX == /opt/boost-1.61.0 (say) or download directly into $PREFIX makes not much of a difference.

...

Yes, but having a tool to retrieve these requirements could change the way libraries are tested. Instead they can be tested against just its dependencies using `cget build --test` instead of needing a full checkout.

That's a good point. Decentralizing the tests might be a good idea.

Plus the libraries can take advantage of travis and appveyor for testing.

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

On Thu, Apr 14, 2016 at 10:09 AM, Rene Rivera <grafikrobot@gmail.com> wrote:

On Wed, Apr 13, 2016 at 5:37 PM, P F <pfultz2@yahoo.com> wrote:

...

Boost.Predef(I am not sure if it depends on other libraries).

Predef doesn't have any external dependencies for users. But does depend on Boost Build and Boost Book for testing and doc building (additive respective).

Sorry.. Meant Quickbook (not Boost Book). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/13/16 3:38 PM, Stephen Kelly wrote:

Robert Ramey wrote:

...

On 4/13/16 1:08 PM, Stephen Kelly wrote:

...

boost@glenstark.net wrote:

...

what to do now?

http://thread.gmane.org/gmane.comp.lib.boost.build/27386

I found this to be interesting.

Then I guess you've updated your thinking.

http://thread.gmane.org/gmane.comp.lib.boost.devel/264253/focus=264272

Hmmm - I forgot this. But it looks to be identical idea that I'm proposing now.

...

Ideally, users would be able to make use of such a file and this would motivate library authors to include such a file with their libraries.

Part of the confusion seems to be that you think this is about boost developers using cmake to develop their boost library.

It is not about that at all.

It is to me. Longer term it's about allowing developers who don't want to depend on boost build to incorporate a boost library.

This is about boost-users who use cmake.

Agreed. Adding a CMakeLists file to any random boost library does not help them. I've done it for one library (actually two serialization and safe integers) and I've found it very helpful. a) I get my IDE project built and maintained without extra work. b) I don't have to use boost build for a simple project which uses boost.

What I described in the link above does help them.

Maybe, but I'm doubtful that adding another feature to boost build would help anyone. In my opinion it's already too complex and too fragile. Robert Ramey

On Apr 13, 2016, at 3:08 PM, Stephen Kelly <hello@steveire.com> wrote:

boost@glenstark.net wrote:

...

what to do now?

http://thread.gmane.org/gmane.comp.lib.boost.build/27386

It would be nice to support both cmake export targets and pkg-config. The nice thing about pkg-config is that it is completely build-independent.

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