[boost] Cmake

[Peter Dimov via Boost]

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

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

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

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

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

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

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

At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck. 5-6 in particular require that all
Jamfiles are ported at once, which is a serious undertaking for a
questionable benefit as what we have already works.

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

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

This repository uses git submodules in ext/ to bring in Boost.System (our
guinea pig) and its dependencies, then uses them via add_subdirectory in

https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt

The required CMake infrastructure is on branch feature/cmake in those six
libraries (assert, config, core, predef, system, winapi.) It consists of
CMakeLists.txt in the root:

https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67429b/CMakeLists.txt

and supporting .cmake files in cmake/ :

https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b67429b/cmake

The goal here is for Boost library developers to be able to remain ignorant
of CMake if they so choose; so of those files, only sources.cmake requires
their input (it's empty for header-only, so those require nothing at all.)

BoostVersion.cmake and default.cmake are common for all libraries and are
copied from the superproject. dependencies.cmake is automatically generated
with boostdep. There is a Jamfile in cmake/ that updates these three files:

https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67429b/cmake/Jamfile

and the intent is for this to be done automatically in a superproject script
that invokes "b2 cmake" for the superproject:

https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile

which in turn invokes "b2 cmake" in each library having "cmake/Jamfile".

Copying BoostVersion.cmake and default.cmake, instead of referring to them,
allows libraries to be used without a superproject, to support scenarios (2)
and (3) above. (Scenario (3) is also supported by default.cmake.)

What remains to be done is (a) to extend this to the rest of the Boost
libraries, if we decide to do so, which would require figuring out a way to
cope with the numeric/ irregular libraries, and (b) support for scenario (1)
above.

Scenario (1), that is, `b2 install` making the installed Boost available for
CMake find_package use, is an entirely separate undertaking, completely
independent of what I've done - except for possibly reusing the
dependencies.cmake files. It would entail generating
boost_libname-config.cmake and boost_libname-config-version.cmake files for
each library, and boost_libname-config-<suffix>.cmake subconfiguration files
for each build variant (toolset, variant=debug/release, link=static/shared,
runtime-link=static/shared, runtime-debugging=on/off,
threading=single/multi, and possibly python-debugging=on/off.)

This would probably require us to define CMake variables controlling these
features, such as BOOST_BUILD_TOOLSET, BOOST_BUILD_VARIANT, BOOST_LINK_TYPE,
BOOST_RUNTIME_LINK, and so on, with them having appropriate default values
inferred from the CMake environment.

Then, boost_system-config-vc141-mt-gd-1_65.cmake will check these values and
if BOOST_BUILD_TOOLSET is "vc141", BOOST_LINK_TYPE is SHARED,
BOOST_RUNTIME_LINK is SHARED and BOOST_RUNTIME_DEBUGGING is ON, it will
declare an imported target pointing to
boost_system-vc141-mt-gd-1_65.lib/dll, otherwise it would do nothing. (Not
sure how relevant is threading=single/multi today, but in principle, it
should also check BOOST_THREADING == MULTI.)

Generating these -config.cmake files would ideally be done as part of the
`b2 install` procedure and require no changes to the individual libraries.
The changes to the `b2 install` procedure significantly exceed my bjam-fu
however, so if we decide to proceed with this - and I don't see how we could
claim CMake support in a meaningful way without it - the interested parties
would need to figure out a way to make that happen. At this point, I know
what needs to be done, but not how to bring it about.


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

[Gary Furnish via Boost]

I'd like to add a 7) Use cmake to make out of tree custom toolchain
builds easy as in
https://github.com/garyfurnish/boost_tools/blob/master/CMakeLists.txt.
This was originally from
https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake and
I modified it a bit to correctly support out of tree builds and it
seems to work.
By out of tree custom toolchain I mean pass CXX, etc on the command
line and have things "just work" without writing a bunch of jam files
in weird places.

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

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems that
everyone has different ideas as to what this support will entail. After
deliberation and discussions, I have identified the following (separate)
1. The user installs a Boost release as usual with `b2 install`, which makes
the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to link
to them.
3. The user uses CMake to install an individual Boost library, which is then
available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost, in
place of b2.
6. CTest is supported as a way to run the tests for the entire Boost, in
place of b2.
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck. 5-6 in particular require that all
Jamfiles are ported at once, which is a serious undertaking for a
questionable benefit as what we have already works.
https://github.com/pdimov/boost-cmake-demo-2
This repository uses git submodules in ext/ to bring in Boost.System (our
guinea pig) and its dependencies, then uses them via add_subdirectory in
https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt
The required CMake infrastructure is on branch feature/cmake in those six
libraries (assert, config, core, predef, system, winapi.) It consists of
https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67429b/CMakeLists.txt
https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b67429b/cmake
The goal here is for Boost library developers to be able to remain ignorant
of CMake if they so choose; so of those files, only sources.cmake requires
their input (it's empty for header-only, so those require nothing at all.)
BoostVersion.cmake and default.cmake are common for all libraries and are
copied from the superproject. dependencies.cmake is automatically generated
https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67429b/cmake/Jamfile
and the intent is for this to be done automatically in a superproject script
https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile
which in turn invokes "b2 cmake" in each library having "cmake/Jamfile".
Copying BoostVersion.cmake and default.cmake, instead of referring to them,
allows libraries to be used without a superproject, to support scenarios (2)
and (3) above. (Scenario (3) is also supported by default.cmake.)
What remains to be done is (a) to extend this to the rest of the Boost
libraries, if we decide to do so, which would require figuring out a way to
cope with the numeric/ irregular libraries, and (b) support for scenario (1)
above.
Scenario (1), that is, `b2 install` making the installed Boost available for
CMake find_package use, is an entirely separate undertaking, completely
independent of what I've done - except for possibly reusing the
dependencies.cmake files. It would entail generating
boost_libname-config.cmake and boost_libname-config-version.cmake files for
each library, and boost_libname-config-<suffix>.cmake subconfiguration files
for each build variant (toolset, variant=debug/release, link=static/shared,
runtime-link=static/shared, runtime-debugging=on/off,
threading=single/multi, and possibly python-debugging=on/off.)
This would probably require us to define CMake variables controlling these
features, such as BOOST_BUILD_TOOLSET, BOOST_BUILD_VARIANT, BOOST_LINK_TYPE,
BOOST_RUNTIME_LINK, and so on, with them having appropriate default values
inferred from the CMake environment.
Then, boost_system-config-vc141-mt-gd-1_65.cmake will check these values and
if BOOST_BUILD_TOOLSET is "vc141", BOOST_LINK_TYPE is SHARED,
BOOST_RUNTIME_LINK is SHARED and BOOST_RUNTIME_DEBUGGING is ON, it will
declare an imported target pointing to
boost_system-vc141-mt-gd-1_65.lib/dll, otherwise it would do nothing. (Not
sure how relevant is threading=single/multi today, but in principle, it
should also check BOOST_THREADING == MULTI.)
Generating these -config.cmake files would ideally be done as part of the
`b2 install` procedure and require no changes to the individual libraries.
The changes to the `b2 install` procedure significantly exceed my bjam-fu
however, so if we decide to proceed with this - and I don't see how we could
claim CMake support in a meaningful way without it - the interested parties
would need to figure out a way to make that happen. At this point, I know
what needs to be done, but not how to bring it about.
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Vinnie Falco via Boost]

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

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

[Robert Ramey via Boost]

Post by Vinnie Falco via Boost
On Sat, Jun 24, 2017 at 1:59 AM, Peter Dimov via Boost

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

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

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

Robert Ramey

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

[Rene Rivera via Boost]

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

Post by Robert Ramey via Boost

Post by Vinnie Falco via Boost
On Sat, Jun 24, 2017 at 1:59 AM, Peter Dimov via Boost

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

I've seen the innards, surface, and operation of the VS and Xcode projects
generated by cmake and I'd loath to to use them. Hence I ask.. Would it be
better to generate those with something else? Especially something that
maps more directly to the b2 definitions. I don't know what else exist to
do this. But just wondering since we are talking about a much smaller
audience than N<5.

[Vinnie Falco via Boost]

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

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

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

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

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

[Rene Rivera via Boost]

On Sat, Jun 24, 2017 at 10:48 AM, Vinnie Falco via Boost <

Post by Vinnie Falco via Boost
On Sat, Jun 24, 2017 at 8:45 AM, Rene Rivera via Boost

Post by Rene Rivera via Boost
I've seen the innards, surface, and operation of the VS and Xcode

projects

Post by Rene Rivera via Boost
generated by cmake and I'd loath to to use them.

I can't speak for Xcode but I've been using the VS projects for a
while now and they are great. I've written a couple of quality-of-life
http://i.imgur.com/dBWLuUn.png
Can you be more specific about what issues you have with generated VS
projects? Perhaps they are easily addressed.

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

[Vinnie Falco via Boost]

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

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

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

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

[Rene Rivera via Boost]

On Sat, Jun 24, 2017 at 11:01 AM, Vinnie Falco via Boost <

Post by Vinnie Falco via Boost
On Sat, Jun 24, 2017 at 9:00 AM, Rene Rivera via Boost

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

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

Perhaps it depends on what features of cmake you use.. I only know enough
cmake to deal with build problems in client projects. And the ones I've
dealt with tend to use the gamut of cmake features. Particularly the
install targets.

[John McFarlane via Boost]

On the subject of VS, has it been mentioned yet that VS2017 happily loads
CMake projects without the need for an .sln file? For sure, explicitly
building project files for older releases is a necessity but if you want to
promote uptake among fresh users with less expertise, *please* make sure
that when they open the Boost folder from VS2017, things works properly.

The same goes for CLion: just point it to a folder with CMakeLists.txt and
CLion is ready to compile, debug and test at the press of a button. Who
knows which other IDEs already provide this convenience or are planning to
in the near future?

Post by Rene Rivera via Boost
On Sat, Jun 24, 2017 at 11:01 AM, Vinnie Falco via Boost <

Post by Vinnie Falco via Boost
On Sat, Jun 24, 2017 at 9:00 AM, Rene Rivera via Boost

Post by Rene Rivera via Boost
One of the issues that I've seen is that the generated project files

are

Post by Vinnie Falco via Boost

Post by Rene Rivera via Boost
just shells around cmake invocations of all kinds. As opposed to direct
project declarations.

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

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

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

[Niall Douglas via Boost]

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

The project files generated by cmake are native to that build system.

cmake injects a prebuild call to cmake to check if any cmake files have
been changed, if so it rebuilds the build system and rebootstraps the build.

Niall

[Gary Furnish via Boost]

This is a pretty well known race condition that I haven't seen a fix
for yet. The workaround is multiple src directories if you might call
cmake in parallel after doing something that will trigger a rebuild.
Even I think this is a poor solution and I like CMAKE. I like the
idea of B2, it just doesn't support a bunch of things I would like to
support all that easily.

On Sat, Jun 24, 2017 at 4:10 PM, Niall Douglas via Boost

Post by Niall Douglas via Boost

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

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

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

[degski via Boost]

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

+1, if I can grok it I usually end up creating a new project from scratch,
just to get rid of the CMake stuff so the IDE does not lead a parallel life
and does what *I* want it to do.

degski

[Daniela Engert via Boost]

Post by degski via Boost

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

+1, if I can grok it I usually end up creating a new project from scratch,
just to get rid of the CMake stuff so the IDE does not lead a parallel life
and does what *I* want it to do.

This matches exactly my own experiences with CMake. The disgusting MSVC
project files that it generates make me always run away screaming: the
results are utterly useless for our purposes. Then I spend a minute and
create a tiny tidy project file from scratch which does the very same
and is usable in our environment.

Using Boost-provided well-made CMake configuration files make sense for
me when it comes to finding problems in a Boost library testcase or so.
This would be much easier now with the newly introduced 'open from
CMake' feature in the VS2017 ide into which I have integrated all
compiler versions (past and present) of my interest.

Ciao
Dani

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

[Robert Ramey via Boost]

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

Post by Robert Ramey via Boost
So I would add 7) or 8): Use CMake to generate an IDE project to
build/test a particular library.

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

As far as Xcode is concerned, the projects might be better. The file
hierarchy in the IDE has an extra layer. Tests aren't aren't compatiple
with the xcode test setup. I don't know if that's a problem since I
don't know what the xcode setup provides. Also it doesn't seem to
correctly setup the search directories for include files - I have to
tweak that by hand. Sooo you're probably correct in the idea that a the
XCode project isn't as good as one that I'd make "by hand" ... if I had
nothing else to do. But it does permit me to "BuildAll" or build any
particular target. It permits me to pick a target and execute it and/or
debug it. It does execute my "carpet bombing" serialization library
test suite. When something changes - some global option or something -
I can just regenerate the IDE and it's all consistent. So all in all it
works well for me.

When I think i'm done, I run my traditional b2 build/test with each
compiler I have available with all build,link variants - 4 and use
library status to make my giant test matrix table. This has about 1200
cells - should have no red cells in order to check it in. In other
words, I really only use the CMake generated IDE in order to edit source
code run a smaller number of tests and debug/trace programs.

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

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

Post by Rene Rivera via Boost
But just wondering since we are talking about a much smaller
audience than N<5.

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

Robert Ramey

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

[Rene Rivera via Boost]

On Sat, Jun 24, 2017 at 3:59 AM, Peter Dimov via Boost <

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to link
to them.
3. The user uses CMake to install an individual Boost library, which is
then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost, in
place of b2.
6. CTest is supported as a way to run the tests for the entire Boost, in
place of b2.
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck. 5-6 in particular require that all
Jamfiles are ported at once, which is a serious undertaking for a
questionable benefit as what we have already works.
https://github.com/pdimov/boost-cmake-demo-2
This repository uses git submodules in ext/ to bring in Boost.System (our
guinea pig) and its dependencies, then uses them via add_subdirectory in
https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt
The required CMake infrastructure is on branch feature/cmake in those six
libraries (assert, config, core, predef, system, winapi.) It consists of
https://github.com/boostorg/system/blob/c306d479e8326a68d07e
e7f058a415fe8b67429b/CMakeLists.txt
https://github.com/boostorg/system/tree/c306d479e8326a68d07e
e7f058a415fe8b67429b/cmake
The goal here is for Boost library developers to be able to remain
ignorant of CMake if they so choose; so of those files, only sources.cmake
requires their input (it's empty for header-only, so those require nothing
at all.)
BoostVersion.cmake and default.cmake are common for all libraries and are
copied from the superproject. dependencies.cmake is automatically generated
https://github.com/boostorg/system/blob/c306d479e8326a68d07e
e7f058a415fe8b67429b/cmake/Jamfile
and the intent is for this to be done automatically in a superproject
https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile
which in turn invokes "b2 cmake" in each library having "cmake/Jamfile".

Interesting work. But...

Copying BoostVersion.cmake and default.cmake, instead of referring to them,

Post by Peter Dimov via Boost
allows libraries to be used without a superproject, to support scenarios
(2) and (3) above. (Scenario (3) is also supported by default.cmake.)

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

Generating these -config.cmake files would ideally be done as part of the

Post by Peter Dimov via Boost
`b2 install` procedure and require no changes to the individual libraries.
The changes to the `b2 install` procedure significantly exceed my bjam-fu
however, so if we decide to proceed with this - and I don't see how we
could claim CMake support in a meaningful way without it - the interested
parties would need to figure out a way to make that happen. At this point,
I know what needs to be done, but not how to bring it about.

Would achieving this be made easier by having b2 generate meta-data that
some other program can use to generate the desired files? For example
generating an XML (or JSON) file describing all the installed targets with
variant information.

[Peter Dimov via Boost]

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

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


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

[Stefan Seefeld via Boost]

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

Post by Peter Dimov via Boost
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck.

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

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

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

Stefan

[Rene Rivera via Boost]

On Sat, Jun 24, 2017 at 10:57 AM, Stefan Seefeld via Boost <

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

I've been a "user" of Boost doing #2 in some of my projects. And I wrote b2
support to enable that use case (non-instrusively and external -- unlike
this concept -- so far)

[Stefan Seefeld via Boost]

Post by Rene Rivera via Boost
On Sat, Jun 24, 2017 at 10:57 AM, Stefan Seefeld via Boost <

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

I've been a "user" of Boost doing #2 in some of my projects. And I wrote b2
support to enable that use case (non-instrusively and external -- unlike
this concept -- so far)

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


Stefan

[Rene Rivera via Boost]

On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost <

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

Depends on the project... But generally because I need precise control over
the compilation variant and want it to be uniform over all the external
dependencies. That precise control offers the advantage of isolated and
predictable building for the project regardless of who builds it (other
devs and CI). In other projects it's the only option available as creating
installed libraries is not an option. Specifically when I'm using
emscripten for C++ web development. And since I use b2 in my projects I
have the luxury of referencing the build descriptions in Boost directly.
And hence I can understand the desires of people with other build systems
to do similarly. But at the same time I've also done non-intrusive building
of many different external libraries (i.e. using b2 to build autotools,
make, cmake, etc projects [1]) so I know it's somewhat presumptuous to
expect library authors to cater to every pet build system out there. And
instead prefer authors to document, in prose, how to build their libraries.

[1] I've also done that type of building in other build systems. Mostly
proprietary ones I can't talk about here though.

[P F via Boost]

Post by Rene Rivera via Boost
On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost <

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

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

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

Post by Rene Rivera via Boost
That precise control offers the advantage of isolated and
predictable building for the project regardless of who builds it (other
devs and CI).

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

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



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

[Steven Watanabe via Boost]

AMDG

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

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

In Christ,
Steven Watanabe


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

[Rene Rivera via Boost]

Post by Rene Rivera via Boost
On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost <

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

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

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


I've been doing this before package managers existed that could do that.
And so I haven't found a package manager that will do it as flexible as I
need. The small number of times I've used package managers I've wrapped
them in scripts that provide repeatable installation for my fellow
developers.

Post by Rene Rivera via Boost
That precise control offers the advantage of isolated and
predictable building for the project regardless of who builds it (other
devs and CI).

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


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

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


Every time I've used zlib bzip2 I've built them statically into my projects.

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

[P F via Boost]

Post by P F via Boost

Post by Rene Rivera via Boost
On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost <

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

Depends on the project... But generally because I need precise control

over

Post by Rene Rivera via Boost
the compilation variant and want it to be uniform over all the external
dependencies.

But isn’t that what a package manager does? The point of scenario #1 is
that it enables a package manager or dependency tool to do this.
I've been doing this before package managers existed that could do that.
And so I haven't found a package manager that will do it as flexible as I
need.

What flexibility do you need?

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

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

Post by P F via Boost

Post by Rene Rivera via Boost
That precise control offers the advantage of isolated and
predictable building for the project regardless of who builds it (other
devs and CI).

Yea, but for open-source libraries and distros, they will never build the
software exactly the same way. It can be built in a lot of different
scenarios. This is why autotools came about to handle this.
Except for Boost I don't do open source. All my work is closed source
products. Usually games or game development tools. Where developers doing
installation is counter productive.

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



_______________________________________________
Unsubscribe & other changes: http://lis

[degski via Boost]

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

Specify f.e. "-sZLIB_SOURCE=c:\zlib-1.2.8" "-sBZIP2_SOURCE=c:\\bzip2-1.0.6"
on the bjam command-line and bjam will build those boost libs from source
without issue.

degski

[Gary Furnish via Boost]

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

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

Post by Peter Dimov via Boost
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck.

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

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

Post by Stefan Seefeld via Boost

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

I agree. (In particular, I very much doubt that you'll get the required
buy-in from all maintainers. I for once am strongly opposed to adding
another bit of infrastructure to my project, which I won't be able to
maintain myself.)
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld via Boost]

Post by Gary Furnish via Boost
On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

Post by Peter Dimov via Boost
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck.

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

As good as modularity and encapsulation sound they make it very hard
to test code.

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

Post by Gary Furnish via Boost
Even different distributions sometimes patch packages
of the same version the same without anyway to detect this. If you
don't build boost as part of your program you can't certify its bug
free with tests. And forget certification of bug free between
different versions of boost!

Yeah, now we are plainly in the discussion of Boost's lack of API and
ABI stability.

Post by Gary Furnish via Boost
It is simply not an option to rely on
external libraries when stuff must test clean.

I strongly disagree. Rigorous testing (which includes the clear
distinction between unit testing and integrated testing) doesn't
invalidate encapsulation. Quite the opposite !

Post by Gary Furnish via Boost
What mechanism you use
to do this various but modularity and encapsulation are a dream.

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

Stefan

[Peter Dimov via Boost]

Post by Stefan Seefeld via Boost
Huh ? Test what code ? As a boost user I want to test *my* code, not
boost.

You want to test your code in the same environment that has generated the
bug report. Since so much of Boost is header-only and inlined into your
code, the two are irredeemably intertwined.

It's not that using the system-installed or user-installed Boost wouldn't
work, it would, that's just a different workflow and a different scenario.
It's a difference in philosophy and the two schools of thought don't seem to
understand each other.

Plus, it's just plain easier to tell people "`git clone --recursive
my-wonderful-repo` and run CMake."


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

[Chris Glover via Boost]

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

For what it's worth, no company I have ever worked for has relied on system
installed packages. Everything is either distributed in-tree or fetched
from a package manager, by version, and usually as source. This is true
even for the compilers. The intent is to keep the local build environment
as similar as possible to the continuous build environment.

Of course, that is not the only way to work, and it's not super convenient
if one is working on smaller projects at home, so it's absolutely necessary
to support the spectrum.

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

[Gary Furnish via Boost]

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

On Sat, Jun 24, 2017 at 10:22 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost

Post by Gary Furnish via Boost
On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost
There is considerable interest in Boost supporting CMake, but it seems
that everyone has different ideas as to what this support will entail.
After deliberation and discussions, I have identified the following

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

Post by Peter Dimov via Boost
1. The user installs a Boost release as usual with `b2 install`, which
makes the installation visible to CMake and usable via
find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his
CMake-based project and uses add_subdirectory in his CMakeLists.txt to
link to them.
3. The user uses CMake to install an individual Boost library, which
is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost,
in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost,
in place of b2.

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

Post by Peter Dimov via Boost
At the moment, I think that we should concentrate on (1) and (2) as
providing most bang for the buck.

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

As good as modularity and encapsulation sound they make it very hard
to test code.

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

Post by Gary Furnish via Boost
Even different distributions sometimes patch packages
of the same version the same without anyway to detect this. If you
don't build boost as part of your program you can't certify its bug
free with tests. And forget certification of bug free between
different versions of boost!

Yeah, now we are plainly in the discussion of Boost's lack of API and
ABI stability.

Post by Gary Furnish via Boost
It is simply not an option to rely on
external libraries when stuff must test clean.

I strongly disagree. Rigorous testing (which includes the clear
distinction between unit testing and integrated testing) doesn't
invalidate encapsulation. Quite the opposite !

Post by Gary Furnish via Boost
What mechanism you use
to do this various but modularity and encapsulation are a dream.

Very sad, but luckily doesn't reflect my experience.
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Peter Dimov via Boost]

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

No, I use it in the same way throughout.

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

No. Most are addressed at users of Boost. (6) is admittedly probably of
interest mostly to ourselves.

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

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

Post by Stefan Seefeld via Boost
Modularity and encapsulation doesn't seem to have any value to you, or
does it ?

Not sure what you mean here. You ask me why do I want to support building
only parts of Boost, then ask me whether modularity has any value to me. You
must be using a meaning of the word "modularity" with which I am not
familiar.


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

[Stefan Seefeld via Boost]

Post by Peter Dimov via Boost

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

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

Post by Stefan Seefeld via Boost
Modularity and encapsulation doesn't seem to have any value to you,
or does it ?

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

No, that wasn't my question.

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

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

Stefan

[P F via Boost]

Post by Stefan Seefeld via Boost

Post by Peter Dimov via Boost

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

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

Post by Stefan Seefeld via Boost
Modularity and encapsulation doesn't seem to have any value to you,
or does it ?

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

No, that wasn't my question.

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

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

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



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

[Stefan Seefeld via Boost]

Post by P F via Boost

On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost
While I can see that some people would like the extra control that
provides, I also see lots of problems with this approach.
(And the fact that some of Boost is header-only is entirely irrelevant
to my argument. If there is nothing to build there is nothing to build.)

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

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

Stefan

[paul via Boost]

Post by Stefan Seefeld via Boost

Post by P F via Boost

On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost
While I can see that some people would like the extra control that
provides, I also see lots of problems with this approach.
(And the fact that some of Boost is header-only is entirely irrelevant
to my argument. If there is nothing to build there is nothing to build.)

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

That's an illusion. My point is precisely that we can't "easily support"
both, as it requires from all maintainers to understand all the build
infrastructure.

It doesn't. The point is the authors has a standalone build that gets its
dependencies through `find_package`. The superproject integrates these into a
single build with `add_subdirectry` and it overrides `find_package` to make it
a no-op.

Of course, having our own set of cmake modules would be even better, as it can
help provide easier support for the boost workflow(ie generating -config.cmake
files), and it can help prevent authors from doing things that work in a
standalone build, but not in superprojects(ie using `include_directories`
instead of `target_include_directories`). 

Post by Stefan Seefeld via Boost
It's precisely the lack of encapsulation that causes
this overhead. I'd be happy to include additional files in my library if
it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/ma

[Stefan Seefeld via Boost]

Post by Stefan Seefeld via Boost
It's precisely the lack of encapsulation that causes
this overhead. I'd be happy to include additional files in my library if
it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.
Although, there are libraries like Boost.Python or Boost.Context that have
more complicated build infrastructure, but the nice thing about cmake is that
there is a much larger community to help with the maintenance cost rather than
relying on a few Boost.Build gurus.

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

Stefan

[paul via Boost]

Post by Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
It's precisely the lack of encapsulation that causes
this overhead. I'd be happy to include additional files in my library if
it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.
Although, there are libraries like Boost.Python or Boost.Context that have
more complicated build infrastructure, but the nice thing about cmake is that
there is a much larger community to help with the maintenance cost rather than
relying on a few Boost.Build gurus.

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

Not exactly. The user may have a build problem, but the likeliness that
they(or another user who is reading the issue) know enough cmake to contribute
a fix is very much higher than them knowing enough bjam to provide a fix. 

Its not that users need to go to another community for help, but that part of
the cmake community becomes part of the boost community as well. 

Furthermore, there is already several boost developers who know and understand
cmake that can provide help, so that even if the user doesn't know enough
cmake, someone in the boost community does, so we don't need to direct the
user somewhere else.



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

[Stefan Seefeld via Boost]

Post by paul via Boost

Post by Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
It's precisely the lack of encapsulation that causes
this overhead. I'd be happy to include additional files in my library if
it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.
Although, there are libraries like Boost.Python or Boost.Context that have
more complicated build infrastructure, but the nice thing about cmake is that
there is a much larger community to help with the maintenance cost rather than
relying on a few Boost.Build gurus.

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

Not exactly. The user may have a build problem, but the likeliness that
they(or another user who is reading the issue) know enough cmake to contribute
a fix is very much higher than them knowing enough bjam to provide a fix.

Oh, you are arguing about bjam vs. cmake. I wasn't. (I would agree that
a well-known tool is better than an obscure one).
My point is about having to maintain (and answer questions about) two
infrastructures rather than one.

I don't think it's realistic to assume that Boost as a whole will
switch, at least not over a short period of time. If there was any
lesson to be learned from passed changes to Boost, it's that such a move
will take a very long time, if it's going to finish at all.

Therefore I think it's much better to leave the decision to switch to
individual project maintainers, as on that scale a change is much
quicker to implement, if that's what the (project-) community decides to
do.
And for that to be possible individual projects need more autonomy, and
the whole build infrastructure needs to be modular. Thus, what I propose
is a little script that iterates over all boost components, invoking
some well-defined entry-point on each, which *may* run `b2` locally, or
it may invoke `cmake`. Of course there needs to be an agreed-upon
protocol (what arguments that script needs to accept, what is the
expected outcome of a build, i.e. where are the generated artefacts,
etc.). I strongly believe that such an approach would be by far more
realistic, efficient, and generate less friction and administrative
overhead than a whole-sale move from bjam to cmake.

Stefan

[paul via Boost]

Post by Stefan Seefeld via Boost

Post by paul via Boost

Post by Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
It's precisely the lack of encapsulation that causes
this overhead. I'd be happy to include additional files in my library if
it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.
Although, there are libraries like Boost.Python or Boost.Context that have
more complicated build infrastructure, but the nice thing about cmake
is
that
there is a much larger community to help with the maintenance cost
rather
than
relying on a few Boost.Build gurus.

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

Not exactly. The user may have a build problem, but the likeliness that
they(or another user who is reading the issue) know enough cmake to contribute
a fix is very much higher than them knowing enough bjam to provide a fix. 

Oh, you are arguing about bjam vs. cmake. I wasn't. (I would agree that
a well-known tool is better than an obscure one).
My point is about having to maintain (and answer questions about) two
infrastructures rather than one.
I don't think it's realistic to assume that Boost as a whole will
switch, at least not over a short period of time. If there was any
lesson to be learned from passed changes to Boost, it's that such a move
will take a very long time, if it's going to finish at all.
Therefore I think it's much better to leave the decision to switch to
individual project maintainers, as on that scale a change is much
quicker to implement, if that's what the (project-) community decides to
do.
And for that to be possible individual projects need more autonomy, and
the whole build infrastructure needs to be modular. Thus, what I propose
is a little script that iterates over all boost components, invoking
some well-defined entry-point on each, which *may* run `b2` locally, or
it may invoke `cmake`.

Thats not realistic at all. If I need to use Boost.System, I will say
`find_package(boost_system)`, but if Boost.System builds with b2, then that
won't be available.

There is also other problems as well. Boost.Build can build all variants in
one build tree whereas cmake requires using seperate build trees. Mixing the
two philosophies just makes its confusing for both users.

Post by Stefan Seefeld via Boost
Of course there needs to be an agreed-upon
protocol (what arguments that script needs to accept, what is the
expected outcome of a build, i.e. where are the generated artefacts,
etc.). I strongly believe that such an approach would be by far more
realistic, efficient, and generate less friction and administrative
overhead than a whole-sale move from bjam to cmake.

We could build a meta-build system that can generate builds for other build
systems, but thats what cmake already is, so for cmake it would be a meta-
meta-build system. 

Maybe it might be better to just create a build generator for b2 in cmake.



_______________________________________________
Unsubscribe & other changes

[Peter Dimov via Boost]

The workflow you promote...

Support. The word is support.

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

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

The lack of modularity (and more importantly: encapsulation) here is

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

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

There is something to build, it's just built as part of your project and is
inlined into your code. If you build against Boost 1.53, you get Boost 1.53
embedded into your binary. If you build against 1.65 - 1.65.

There is a way to encapsulate, it's called extern "C". Boost doesn't use it.


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

[P F via Boost]

1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.
3. The user uses CMake to install an individual Boost library, which is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost, in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost, in place of b2.
At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. 5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works.
https://github.com/pdimov/boost-cmake-demo-2
This repository uses git submodules in ext/ to bring in Boost.System (our guinea pig) and its dependencies, then uses them via add_subdirectory in
https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt
https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67429b/CMakeLists.txt
https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b67429b/cmake
The goal here is for Boost library developers to be able to remain ignorant of CMake if they so choose; so of those files, only sources.cmake requires their input (it's empty for header-only, so those require nothing at all.)

I think it would be better for us to use cmake modules for this instead of copying a bunch of cmake files everywhere. I setup a demo using cmake modules here:

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

The library for Boost.System is just:

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

And this works for both `add_subdirectory` build and standalone builds. This will build the library and install -config.cmake files and is simple enough for those who want to remain ignorant of cmake. I think this is also better for maintenance as well, because if we need to make changes in the future, we need to coordinate across several repos.

Also, for authors who would prefer more vanilla cmake, they can write the vanilla cmake. It would be interesting to setup an automated testing infrastructure for cmake to test whether the libraries support these scenarios correctly.



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

[Peter Dimov via Boost]

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

Post by P F via Boost
And this works for both `add_subdirectory` build and standalone builds.

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


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

[P F via Boost]

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

The version and dependency list could be generated by the superproject, like in your example.

Ideally, the version could be a header in `boost/{module}/version.hpp` with macro such as `BOOST_{module}_VERSION`. The `bcm_boost_package` can parse this header to retrieve the version. In fact, bcm already has support for something like this already:

http://bcm.readthedocs.io/en/latest/src/BCMPackage.html#cmdoption-bcm-boost-package-arg-version-header

Although, we may need a whitelist, or someway to deal with libraries that have their own versioning scheme(like Boost.Hana).

For dependencies, we could generate a dependencies.txt file from the superproject, and have an argument for the file rather than write it directly in the cmake file.

Post by P F via Boost
And this works for both `add_subdirectory` build and standalone builds.

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

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/m

[Peter Dimov via Boost]

Post by P F via Boost

Post by Peter Dimov via Boost

Post by P F via Boost
And this works for both `add_subdirectory` build and standalone builds.

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

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

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


_______________________________________________
Unsubscribe & other changes: ht

[P F via Boost]

Post by P F via Boost

Post by P F via Boost
And this works for both `add_subdirectory` build and standalone builds.

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

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

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

No, you just do `include` instead of `add_subdirectory`, but it doesn’t require installation. And in fact, in the case of doing `add_subdirectory(boost)` its completely transparent.



_______________________________________________
Unsubscribe & other changes: http://lists.

[Peter Dimov via Boost]

Post by P F via Boost
No, you just do `include` instead of `add_subdirectory`, but it doesn’t
require installation.

I'm not sure I understand. find_package(BCM) is unconditional in
CMakeLists.txt, right?

https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/libs/system/CMakeLists.txt#L5

What 'include` do you do and where?

Unrelated, why do you need `include(GNUInstallDirs)` here:

https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/bcm/share/bcm/cmake/BCMPackage.cmake#L2

?


_______________________________________________
Unsubscribe & other changes:

[P F via Boost]

Post by P F via Boost
No, you just do `include` instead of `add_subdirectory`, but it doesn’t require installation.

I'm not sure I understand. find_package(BCM) is unconditional in CMakeLists.txt, right?
https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/libs/system/CMakeLists.txt#L5

Yes, but in the superproject I exclude it:

macro(find_package NAME)
if(NOT "${NAME}" MATCHES "^boost_.*$" AND NOT "${NAME}" STREQUAL BCM)
_find_package(${ARGV})
endif()
endmacro()

Alternatively, in the superproject I could append the cmake prefix path:

list(APPEND CMAKE_PREFIX_PATH bcm)

Which would make `find_package(BCM)` work in the subprojects, and the include would not be needed. This might be a better approach.

What 'include` do you do and where?

Thats the `include(bcm/share/bcm/cmake/BCMConfig.cmake)`, here:

https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/CMakeLists.txt#L11

https://github.com/pfultz2/boost-cmake-demo/blob/bcm-demo/bcm/share/bcm/cmake/BCMPackage.cmake#L2
?

Its not needed. I think originally I was going to use that module for the install directories.



_______________________________________________
Unsubscribe & other changes: http://lists

[Edward Diener via Boost]

Post by Peter Dimov via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

Post by Peter Dimov via Boost

Post by P F via Boost
And this works for both `add_subdirectory` build and standalone builds.

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

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

[Robert Ramey via Boost]

Post by Edward Diener via Boost

Post by Peter Dimov via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

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

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

Later

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

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

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

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

Robert Ramey


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

[P F via Boost]

Post by Robert Ramey via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

a) I have and application A which uses the boost::date_time library.
b) But it doesn't serialize dates/times So it doesn't include the date_time/serialization header
c) So application is not dependent upon the serialization library
d) And it doesn't have to include build / maintenance overhead that including the serialization library would entail.
Later
a) I make application B which used the boost::date_time library
b) Part of the app also serializes date_time data
c) So it includes date_time/serialization header
d) And must be linked with the serialization compiled libraries.
My point is that one cannot support the notion of dependencies between libraries outside of the context of a particular application.

That’s what conditionals can be used for. That is, you would build with `-DBOOST_DATE_TIME_WITH_SERIALIZATION=1` to build with serialization. However, boost’s directory structure doesn’t support this well, as you would need multiple include directories for the different options.

A simpler option would be to make a different module. That is if the user would like serialization support for date time, they can do `add_subdirectory(boost_date_time_serialization)` or `find_package(boost_date_time_serialization)`

Post by Robert Ramey via Boost
So dependencies will either have to specified/maintained by hand or one will need a tool which does something like
dependencies A.cpp -> dependent libraries for application A
dependencies B.cpp -> dependent libraries for application B

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



_______________________________________________
Unsubscribe & other changes:

[Edward Diener via Boost]

Post by Robert Ramey via Boost

Post by Edward Diener via Boost

Post by Peter Dimov via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

a) I have and application A which uses the boost::date_time library.
b) But it doesn't serialize dates/times So it doesn't include the
date_time/serialization header
c) So application is not dependent upon the serialization library
d) And it doesn't have to include build / maintenance overhead that
including the serialization library would entail.
Later
a) I make application B which used the boost::date_time library
b) Part of the app also serializes date_time data
c) So it includes date_time/serialization header
d) And must be linked with the serialization compiled libraries.
My point is that one cannot support the notion of dependencies between
libraries outside of the context of a particular application.
So dependencies will either have to specified/maintained by hand or one
will need a tool which does something like
dependencies A.cpp -> dependent libraries for application A
dependencies B.cpp -> dependent libraries for application B

How is a library supposed to know what your application needs ? That is
not its responsibility. Doesn't CMake allow manipulation of what an
application needs at some higher level ? When I have used CMake to build
LLVM/Clang it certainly allowed me to choose what I wanted for my
particular build even though LLVM/CLang provide a whole slew of
CMakeLists.txt files. If we cannot setup CMake pretty easily for Boost
libraries so that the end-user can manipulate builds and tests for his
needs our CMake setup will be worthless.

Post by Robert Ramey via Boost
Robert Ramey

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

[Robert Ramey via Boost]

Post by Edward Diener via Boost

Post by Robert Ramey via Boost
dependencies A.cpp -> dependent libraries for application A
dependencies B.cpp -> dependent libraries for application B

How is a library supposed to know what your application needs

Right it can't. That is my point.

One cannot say that the date/time library dependent upon the
serialization library just because it includes some of the serialization
library headers. You can't say that any time the date/time is used the
serialization library has to be included as well. You have to wait
until you see the final application to know whether the part of
date/time you actually used includes the serialization library.

There seems to be an idea that one can build library dependencies
automatically by recurrsively scanning the source code #include files.
This examples shows why this cannot be done. Dependency outside of a
particular application is undefined.


? That is not its responsibility. Doesn't CMake allow manipulation of
what an

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

If we cannot setup CMake pretty easily for Boost

Post by Edward Diener via Boost
libraries so that the end-user can manipulate builds and tests for his
needs our CMake setup will be worthless.

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

Robert Ramey

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

[P F via Boost]

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

What do you mean generated on the fly? This is stored in each repo so that the user can add the libraries as submodules to their project. At release time, I believe, we would run `b2 cmake` and update the dependencies and version. Perhaps we could update the source list as well. Alternatively, we could glob the source file in cmake:

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

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



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

[Edward Diener via Boost]

Post by P F via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

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

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

Post by P F via Boost
file(GLOB SOURCES src/*.cpp)
bcm_boost_package(system
VERSION 1.64
SOURCES
${SOURCES}
DEPENDS
assert
config
core
predef
)
This, in general, is considered bad practice, but might be better than waiting until release to update the source list. Perhaps, there is a better workflow for this.

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

[P F via Boost]

Post by P F via Boost

Post by P F via Boost
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
bcm_boost_package(system
VERSION 1.64
SOURCES
src/error_code.cpp
DEPENDS
assert
config
core
predef
)

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

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

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

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

I don’t think it would be hard at all. Although, some authors may want to maintain their own cmake, so we don’t want to override the CMakeLists.txt files per-se, and just provide the files such as dependencies.txt and version.hpp, at least from the superproject, since its the only one that knows that information.

For source files, we can just have a script that generates the cmake with the source files that the authors can run locally, or the author can update the list(which is fairly easy) or use file globbing if they want.



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

[David Sankel via Boost]

On Sat, Jun 24, 2017 at 4:59 AM, Peter Dimov via Boost <

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

Thanks,

David

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

[Peter Dimov via Boost]

Post by David Sankel via Boost

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

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

and Stephen Kelly and Daniel Pfeiffer's

https://github.com/boost-cmake/boost-cmake

All that is however about the (effective) content of CMakeLists.txt, and
this is not the main, or at least not the only, focus of the demo. It also
shows how I think things could be organized so that library authors do not
need to maintain the cmake infrastructure (short of adding or removing a
source file from the list of sources - something that can also be automated,
although I don't see it as that high a burden, as it requires no
cmake-specific knowledge.)

Unless, of course, the author does want to maintain the cmake infrastructure
himself, in which case he'll simply not use default.cmake, but write his
own.


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

[Niall Douglas via Boost]

Post by Peter Dimov via Boost

Post by David Sankel via Boost

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

I don't see anything in Peter's example which couldn't be implemented in
cmake 2.8? It's best practice cmake 2.8-3.0 no doubt, but cmake >= 3.5,
I don't think so.

I find the lack of clear separation of concerns problematic; the lack of
cmake support for header only libraries unfortunate; far too much hard
coding of volatile config goes on inside each library; I am unsure how
this design would be easily adaptable to C++ Modules support; I don't
find this approach particularly reusable by unknown third party cmake,
though I can see why Peter will disagree with that.

But one or two minor quibbles aside, as a cmake 2.8 design, it's great,
and I'd far prefer this approach over what some others have suggested.
Indeed its single biggest strength will be its strong familiarity to
cmake users, the cmake gurus have done a great job banging the drum on
designs like this over what came before.

Niall

[Peter Dimov via Boost]

the lack of cmake support for header only libraries unfortunate;

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


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

[Niall Douglas via Boost]

Post by Peter Dimov via Boost

the lack of cmake support for header only libraries unfortunate;

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

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

Niall

[Peter Dimov via Boost]

Post by Niall Douglas via Boost
Ok, my wording wasn't clear: "the lack of disambiguation to cmake of
header, static and shared libraries unfortunate"

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


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

[Niall Douglas via Boost]

Post by Peter Dimov via Boost

Post by Niall Douglas via Boost
Ok, my wording wasn't clear: "the lack of disambiguation to cmake of
header, static and shared libraries unfortunate"

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

They are definitely not an innovation. That target-based, fully
declarative cmake programming was always the end goal of cmake 3. If you
read the discussions on cmake-dev that was always clear.

Now, I'll grant you that the choice to eliminate as much detail as
possible from nonroot CMakeLists is unusual, and could be called an
"innovation". However as anyone who has been dropped into mature
corporate cmake knows, rootlevel reprogramming of child cmake is both
very common and very well understood (search for all cmake stackoverflow
posts by my former work colleague Fraser, he taught me most of my low
level cmake tricks. Lovely guy too, he lurked here on boost-dev for many
years, I don't believe he ever posted).

Most would consider rootlevel reprogramming an anti-pattern to be
avoided, and normally when you are overriding hard coded decisions in
child cmake then it is. But if the child cmake never hard coded anything
it didn't have to, suddenly it becomes a powerful form of abstraction
and reusability. Well, powerful for cmake at least.

But as I've said many times now, whomever ends up implementing this will
decide, so much if not most of this discussion is moot and it always
was. The real question is who will be implementing this and how far it
will be taken within what time frame, and until the proposal lands at
the SC and they take a decision, I'm not sure if further bike shedding
here is worth anybody's time.

Niall

[Peter Dimov via Boost]

Post by Niall Douglas via Boost

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

They are definitely not an innovation.

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


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

[Robert Ramey via Boost]

Post by Peter Dimov via Boost

Post by Peter Dimov via Boost
Yes, as much as I like - in principle - the separate

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

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

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

Post by Peter Dimov via Boost
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

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

[P F via Boost]

Post by Niall Douglas via Boost

Post by Peter Dimov via Boost

Post by David Sankel via Boost

Post by Peter Dimov via Boost
https://github.com/pdimov/boost-cmake-demo-2

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

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

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

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

Post by Niall Douglas via Boost
It's best practice cmake 2.8-3.0 no doubt, but cmake >= 3.5,
I don't think so.

Says who? We are following the guidelines presented by Daniel Pfeifer on how to setup cmake in 2017 using the latest version of cmake.

More importantly, this handles the different scenarios users want to use cmake for(ie supporting both `find_package` and `add_subdirectory`). What you presented does not, nor is there a demo or document on how this can be made to support the different scenarios.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.or

[Niall Douglas via Boost]

Post by P F via Boost

Post by Niall Douglas via Boost
I don't see anything in Peter's example which couldn't be implemented in
cmake 2.8?

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

Ok, more poor wording by me. Peter's cmake makes no use of cmake 3 only
design patterns that I could see. The old trick of implementing
interface libraries in cmake 2.8 (and often necessary before cmake 3.5)
was via empty static libraries, so you generate from cmake an empty
source file and compile it into an empty static library, then propagate
header dependencies etc. It's an easy function to write, and gets you
80% of proper cmake 3 interface libraries.

find_dependency() isn't needed nor ought to be in any Boost cmake
implementation for all the many good reasons I've already repeatedly
listed ad nauseum by now. It's way overkill for Boost's needs and
introduces significant added complexity and maintenance. If it's in any
final design, I would consider such a design to be of poor quality not
properly thought through.

Niall

[paul via Boost]

Post by Niall Douglas via Boost

Post by P F via Boost

Post by Niall Douglas via Boost
I don't see anything in Peter's example which couldn't be implemented in
cmake 2.8?

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

Ok, more poor wording by me. Peter's cmake makes no use of cmake 3 only
design patterns that I could see.

What cmake 3 only design patterns? Peter's implementation is using Daniel
Pfeifer's and Stephen Kelley's design patterns for cmake 3.

Post by Niall Douglas via Boost
The old trick of implementing
interface libraries in cmake 2.8 (and often necessary before cmake 3.5)

Cmake 3.5? You claim in the source, its so that `add_dependencies` works on
header-only(which is a cmake 3.3 feature), but you don't ever use that feature
anyways.

Post by Niall Douglas via Boost
was via empty static libraries, so you generate from cmake an empty
source file and compile it into an empty static library, then propagate
header dependencies etc. It's an easy function to write, and gets you
80% of proper cmake 3 interface libraries.

If you are going to emulate things, you could say your implementation is cmake
2.8 as well.

Post by Niall Douglas via Boost
find_dependency() isn't needed nor ought to be in any Boost cmake
implementation for all the many good reasons I've already repeatedly
listed ad nauseum by now.

It is needed to find transitive dependencies in a package configuration file.

Post by Niall Douglas via Boost
It's way overkill for Boost's needs and
introduces significant added complexity and maintenance. If it's in any
final design, I would consider such a design to be of poor quality not
properly thought through.

I disagree, I think Daniel Pfeifer's and Stephen Kelley's design is very well
though out.



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