[boost] Proposal for moving Boost to CMake

[David Sankel via Boost]

Howdy all,

This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.

The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based on
Google trends graphs and discussions with others at the conferences I attend
(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater C++
community and making Boost more accessible would be of great utility.

* To ease the migration path, both Boost.Build (the current jam-based build
system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be used
instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.
* We would work with CMake towards eventually taking over maintenance of the
FindBoost module distributed with CMake.

I see this progressing with several milestones.

1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.

Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.

One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.

Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.

Thanks for your consideration.

-- David Sankel

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

[Vinnie Falco via Boost]

On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost

Post by David Sankel via Boost
This is a request for comments on a possible path for
migrating Boost's build system to CMake.

It seems there are two concerns here:

1. Providing an up-to-date "FindBoost" module with each Boost release
so that *users* who build their projects with CMake can easily find
the Boost dependencies, and

2. Allowing Boost itself to be built using CMake as an alternative to bjam

Do we need both, or is it possible to satisfy the majority of user
wants by implementing only number 1 above?

Thanks

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

[Robert Ramey via Boost]

Post by Vinnie Falco via Boost
On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost

Post by David Sankel via Boost
This is a request for comments on a possible path for
migrating Boost's build system to CMake.

1. Providing an up-to-date "FindBoost" module with each Boost release
so that *users* who build their projects with CMake can easily find
the Boost dependencies, and

a) I use XCode IDE for development of my Boost projects. So I'm
familiar with it.

b) CMake FindBoost doesn't work as far as I'm concerned. This means
that after creating an IDE project, I have to tweak it to make it work.
I looked into the FindBoost code and, as it must, it tries to
automagically figure out where the libraries are, which versions, share
vs linked etc.etc. It's fairly complex and would require a lot of work
to work on a more or less reliable bases.

In short, my view is that CMake doesn't really work - it's more that it
can be made to work.

Post by Vinnie Falco via Boost
2. Allowing Boost itself to be built using CMake as an alternative to bjam
Do we need both, or is it possible to satisfy the majority of user
wants by implementing only number 1 above?

We don't even have to address that question since of necessity, there
would have to be a transition whereby both are supported. Eventually
this would sort itself out.

Post by Vinnie Falco via Boost
Thanks
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 8:38 PM, Robert Ramey via Boost <

Post by Vinnie Falco via Boost
On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost

Post by David Sankel via Boost
This is a request for comments on a possible path for
migrating Boost's build system to CMake.

1. Providing an up-to-date "FindBoost" module with each Boost release
so that *users* who build their projects with CMake can easily find
the Boost dependencies, and

a) I use XCode IDE for development of my Boost projects. So I'm familiar
with it.
b) CMake FindBoost doesn't work as far as I'm concerned. This means that
after creating an IDE project, I have to tweak it to make it work. I looked
into the FindBoost code and, as it must, it tries to automagically figure
out where the libraries are, which versions, share vs linked etc.etc. It's
fairly complex and would require a lot of work to work on a more or less
reliable bases.
In short, my view is that CMake doesn't really work - it's more that it
can be made to work.

Sorry, I could not make any sense of this.

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 7:48 PM, Vinnie Falco via Boost <

Post by Vinnie Falco via Boost
On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost

Post by David Sankel via Boost
This is a request for comments on a possible path for
migrating Boost's build system to CMake.

1. Providing an up-to-date "FindBoost" module with each Boost release
so that *users* who build their projects with CMake can easily find
the Boost dependencies, and

There are a significant number of users who do not use the binary
distribution model for their codebases. Instead, they have the source code
for all their projects (including third-party dependencies like Boost) in
one repository and build everything all at once. These users cannot use
CMake's FindBoost module since it doesn't have the capability to add the
boost source code to the build. They currently have the choice to write and
maintain their own CMake files to build boost, wrap the bjam build with
CMake code, or just don't bother using Boost since it is too big a hassle.
I've seen all three of these.

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

[Edward Diener via Boost]

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.
The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based on
Google trends graphs and discussions with others at the conferences I attend
(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater C++
community and making Boost more accessible would be of great utility.
* To ease the migration path, both Boost.Build (the current jam-based build
system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be used
instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.
* We would work with CMake towards eventually taking over maintenance of the
FindBoost module distributed with CMake.

As has been pointed out by many people Boost Build does a number of
things for building, testing, and creating documentation for a library
which CMake does not do, whereas I have never seen any evidence of a
single thing which CMake does which Boost Build cannot do. So in effect
you are asking developers to give up a superior build product for one
that is vastly more popular.

I have even asked about a CMake deficiency on the CMake mailing list,
only to receive no answer at all. That is why I have the impression that
CMake deficiencies are just ignored.

I do not want to debate. I am still waiting for anyone to show me CMake
building all Boost libraries, including builds, tests, and
documentation, with the same results that Boost Build currently does.
Anyone ? Otherwise this endless suggestion of moving to CMake, because
it is so popular with the general programming world, seems an absolute
dead end to me.

BTW I am no great lover of bjam syntax or the undocumented internal
complexities of the Boost Build system. But unless I can be shown a
CMake system that can practically do what Boost Build does for
maintaining libraries I believe your suggestion is a non-starter.

Post by David Sankel via Boost
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.
Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.
One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.
Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.
Thanks for your consideration.
-- David Sankel

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 8:27 PM, Edward Diener via Boost <

As has been pointed out by many people Boost Build does a number of things
for building, testing, and creating documentation for a library which CMake
does not do, whereas I have never seen any evidence of a single thing which
CMake does which Boost Build cannot do. So in effect you are asking
developers to give up a superior build product for one that is vastly more
popular.

That is a correct assessment.

I have even asked about a CMake deficiency on the CMake mailing list, only
to receive no answer at all. That is why I have the impression that CMake
deficiencies are just ignored.

Uhm, this happens with any Open Source project with a big enough user base.
Can you link to your post?

I do not want to debate. I am still waiting for anyone to show me CMake

building all Boost libraries, including builds, tests, and documentation,
with the same results that Boost Build currently does. Anyone ? Otherwise
this endless suggestion of moving to CMake, because it is so popular with
the general programming world, seems an absolute dead end to me.
BTW I am no great lover of bjam syntax or the undocumented internal
complexities of the Boost Build system. But unless I can be shown a CMake
system that can practically do what Boost Build does for maintaining
libraries I believe your suggestion is a non-starter.

This sounds a lot like "do the work first and then I'll tell you whether or
not your time was wasted". This is a significant time and probably monetary
investment, something worthy of discussion *before* the work is done.

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

[Edward Diener via Boost]

Post by David Sankel via Boost
On Fri, Jun 16, 2017 at 8:27 PM, Edward Diener via Boost <

As has been pointed out by many people Boost Build does a number of things
for building, testing, and creating documentation for a library which CMake
does not do, whereas I have never seen any evidence of a single thing which
CMake does which Boost Build cannot do. So in effect you are asking
developers to give up a superior build product for one that is vastly more
popular.

That is a correct assessment.

I have even asked about a CMake deficiency on the CMake mailing list, only
to receive no answer at all. That is why I have the impression that CMake
deficiencies are just ignored.

Uhm, this happens with any Open Source project with a big enough user base.
Can you link to your post?
I do not want to debate. I am still waiting for anyone to show me CMake

building all Boost libraries, including builds, tests, and documentation,
with the same results that Boost Build currently does. Anyone ? Otherwise
this endless suggestion of moving to CMake, because it is so popular with
the general programming world, seems an absolute dead end to me.
BTW I am no great lover of bjam syntax or the undocumented internal
complexities of the Boost Build system. But unless I can be shown a CMake
system that can practically do what Boost Build does for maintaining
libraries I believe your suggestion is a non-starter.

This sounds a lot like "do the work first and then I'll tell you whether or
not your time was wasted". This is a significant time and probably monetary
investment, something worthy of discussion *before* the work is done.

You seem to expect Boost to decide to move from Boost Build to CMake
without even a proof of concept that shows that CMake can build,test,
and/or create docs as Boost Build is currently able to do for all Boost
libraries. I would never expect Boost to do that.


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

[Niall Douglas via Boost]

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Instead of nasty cmake 2 era FindBoost(), why can't end users use the
modern cmake 3 pattern:

```
find_package(boost COMPONENTS asio REQUIRED)
target_link_libraries(myprogram PRIVATE boost::asio)
```

No cmake innovation needed to do this. This is 100% vanilla cmake 3.

BTW David if you do decide to go down this route, you and the Steering
Committee should seriously consider contracting Stephen Kelly to advise
on doing this properly. He's the primary architect of cmake 3's
improvements. He knows more about how to do this right than *anybody* on
this list.

It would also make good on the way he was chased away from here for the
sin of changing other people's code without their permission despite
that Dave had asked him to and given him the svn commit privs to do so.
It would be the least the Steering Committee could do to put that wrong
right and officially say sorry.

Niall

[Robert Ramey via Boost]

Post by Niall Douglas via Boost
It would also make good on the way he was chased away from here for the
sin of changing other people's code without their permission

He didn't test his changes. It took me weeks to get things running again.

Post by Niall Douglas via Boost
It would be the least the Steering Committee could do to put that wrong
right and officially say sorry.

I won't wait for any committee. I'll say writh now that I'm sorry for
the whole episode.

Robert Ramey

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

[Edward Diener via Boost]

Post by Niall Douglas via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Instead of nasty cmake 2 era FindBoost(), why can't end users use the
```
find_package(boost COMPONENTS asio REQUIRED)
target_link_libraries(myprogram PRIVATE boost::asio)
```
No cmake innovation needed to do this. This is 100% vanilla cmake 3.
BTW David if you do decide to go down this route, you and the Steering
Committee should seriously consider contracting Stephen Kelly to advise
on doing this properly. He's the primary architect of cmake 3's
improvements. He knows more about how to do this right than *anybody* on
this list.
It would also make good on the way he was chased away from here for the
sin of changing other people's code without their permission despite
that Dave had asked him to and given him the svn commit privs to do so.
It would be the least the Steering Committee could do to put that wrong
right and officially say sorry.

He was not "chased away" and the rest of your interpretation of what
happened is completely wrong.

Post by Niall Douglas via Boost
Niall

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 8:30 PM, Niall Douglas via Boost <

Post by Niall Douglas via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries,

Boost

Post by David Sankel via Boost
targets would be built from source as part of the user build.

Instead of nasty cmake 2 era FindBoost(), why can't end users use the
```
find_package(boost COMPONENTS asio REQUIRED)
target_link_libraries(myprogram PRIVATE boost::asio)
```
No cmake innovation needed to do this. This is 100% vanilla cmake 3.

Thanks for pointing this out. This is exactly what I had in mind.

Post by Niall Douglas via Boost
BTW David if you do decide to go down this route, you and the Steering
Committee should seriously consider contracting Stephen Kelly to advise
on doing this properly. He's the primary architect of cmake 3's
improvements. He knows more about how to do this right than *anybody* on
this list.

Thanks for the suggestion.

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

[Stefan Seefeld via Boost]

Hi David,

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.

While I agree that there is a need to improve the current
infrastructure, I disagree on your proposal, not because I have any
well-formed opinion on CMake (I haven't), but because I think the
problem is more fundamental, and can't be solved by another switch of
tools. The problem isn't a technical one, it's systemic / organisational.

Boost has grown a lot, and neither its organization nor its
infrastructure (of which the build system is just one part) doesn't
scale well. So instead of substituting a tool, I would like to invite
you to consider a few organizational changes.
Notably, I would like to see the long-stalled modularization process to
be picked up again and be continued (and completed ?). Instead of
managing all of Boost in terms of a single github super-repository, a
single build system, a single issue tracker, a single website (etc.,
etc.), I'd like to see all of this to be broken out into separate
projects, where most of the tool choices could be handled locally, i.e.
per project.
The role of Boost as the organization would be that of a umbrella
organization that defines certain guidelines, provides services
(financial, legal, etc.), but otherwise tries hard to stay out of the
way to accelerate rather than hinder development.

Looking at the current set of libraries, I can see a number that already
are relatively independent, so the remaining change to complete the
"modularization" is minor. (Take as an example Boost.Python, which few
other Boost libraries depend on, and if so, only optionally so.)
The rest could be incrementally separated, eventually leaving a single
"Boost core" project, which everything else depends on.

Once there, you could rephrase your proposal for each individual library
project to consider to switch. There wouldn't be a huge discussion
flooding everyone's inbox, and consuming lots of time and energy from
way too many people. Smaller groups of people would much quicker come to
a conclusion, and the implementation of the change would be swift.

At least that's one dream I keep having...

Stefan

[Robert Ramey via Boost]

Post by Stefan Seefeld via Boost
Hi David,

The problem isn't a technical one, it's systemic / organisational.

Agreed.

Post by Stefan Seefeld via Boost
Boost has grown a lot, and neither its organization nor its
infrastructure (of which the build system is just one part) doesn't
scale well. So instead of substituting a tool, I would like to invite
you to consider a few organizational changes.
Notably, I would like to see the long-stalled modularization process to
be picked up again and be continued (and completed ?). Instead of
managing all of Boost in terms of a single github super-repository, a
single build system, a single issue tracker, a single website (etc.,
etc.), I'd like to see all of this to be broken out into separate
projects, where most of the tool choices could be handled locally, i.e.
per project
The role of Boost as the organization would be that of a umbrella
organization that defines certain guidelines, provides services
(financial, legal, etc.), but otherwise tries hard to stay out of the
way to accelerate rather than hinder development.
Looking at the current set of libraries, I can see a number that already
are relatively independent, so the remaining change to complete the
"modularization" is minor. (Take as an example Boost.Python, which few
other Boost libraries depend on, and if so, only optionally so.)
The rest could be incrementally separated, eventually leaving a single
"Boost core" project, which everything else depends on.
Once there, you could rephrase your proposal for each individual library
project to consider to switch. There wouldn't be a huge discussion
flooding everyone's inbox, and consuming lots of time and energy from
way too many people. Smaller groups of people would much quicker come to
a conclusion, and the implementation of the change would be swift.
At least that's one dream I keep having...

This is the vision that I had when I made my proposal at C++Now titled
Boost 2.0.

It's also the vision that I had/have in mind when I create the Boost
Library Incubator.

I believe the two lines about fleshout the vision you've articulated so
you've got two votes - (not that it's up for a vote).

My presentation boost 2.0 was probably my least successful ever. I lost
control of it as it veered into and argument about automatically
generating dependencies. I was sott of struck by lightning. But still
it articulated some ideas which have come to fruition such as the Boost
Library Official Maintainer program and Boost Library Incubator. They
haven't been the total success I would have hoped, but it does seem that
we have less complaints about lack of library maintenance and we are
reviewing more libraries which seem better prepared for review. Of
course maybe it's confirmation bias.

The last time this was discussed on the list, things circled down the
drain of automatic dependencies. Let's not do this again. Let's just
accept that somehow dependencies will be figured out, even if it has to
be done by hand.

The more interesting thing is the decoupling. Let each library decide
which build, test, documentation, deployment, bug tracking system to
use. The Boost Politburo would set requirements rather than design a
specific system. Examples would be:

a) every libary has to have documentation. Documentation has to be
standards conforming. That is it would have to describe libraries in
terms of valid expressions rather than implementation

b) every library has to have a test suite

c) every library has to have a single button download, build and test
functionality.

d) every library has to use a public version control system for it's
source code

e) every library has to use the Boost License

f) every library has to fulfill a minimum set of directory structure
requirements.

f) Review managers cannot accept library into boost if it fails any of
the above.

Of course the Boost web page would have a portion which looks like the
Boost library Incubator. So be it. Actually I've even considered just
adding a page for each current boost library. The library dropdown would
then specify accepted boost libraries, proposed boost libraries, etc.

Building of all of boost would of just the sequence of "one button"
download build and test for each library.

I was going to put this in a separate post by you started down this path.

Robert Ramey






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

[Stefan Seefeld via Boost]

[...]

Post by Robert Ramey via Boost

Post by Stefan Seefeld via Boost
At least that's one dream I keep having...

This is the vision that I had when I made my proposal at C++Now titled
Boost 2.0.
It's also the vision that I had/have in mind when I create the Boost
Library Incubator.
I believe the two lines about fleshout the vision you've articulated
so you've got two votes - (not that it's up for a vote).

That's good to hear (even though it's not up for a vote :-) ).

Post by Robert Ramey via Boost
My presentation boost 2.0 was probably my least successful ever. I
lost control of it as it veered into and argument about automatically
generating dependencies. I was sott of struck by lightning. But still
it articulated some ideas which have come to fruition such as the
Boost Library Official Maintainer program and Boost Library Incubator.

It's funny how most discussions here end up as tool discussions. ("When
the only tool you have is a hammer, every problem looks like a nail.")

Post by Robert Ramey via Boost
They haven't been the total success I would have hoped, but it does
seem that we have less complaints about lack of library maintenance
and we are reviewing more libraries which seem better prepared for
review. Of course maybe it's confirmation bias.
The last time this was discussed on the list, things circled down the
drain of automatic dependencies.

Ditto.

Post by Robert Ramey via Boost
Let's not do this again. Let's just accept that somehow dependencies
will be figured out, even if it has to be done by hand.

Let's be very conscious about the fact that the problem to solve is not
the technical one (which is the easy part !), but the underlying
systemic (social) one. And until that is being addressed, no tool will
help us.

Post by Robert Ramey via Boost
The more interesting thing is the decoupling. Let each library decide
which build, test, documentation, deployment, bug tracking system to
use. The Boost Politburo would set requirements rather than design a
specific system.

Right. And even those requirements would have to be carefully to be
minimally intrusive...

Post by Robert Ramey via Boost
a) every libary has to have documentation. Documentation has to be
standards conforming. That is it would have to describe libraries in
terms of valid expressions rather than implementation

Yes ! (And for avoidance of doubt: "standards conforming" should
exclusively be concerned about the outcome, not the way it is produced
(which is an "implementation").

Post by Robert Ramey via Boost
b) every library has to have a test suite
c) every library has to have a single button download, build and test
functionality.
d) every library has to use a public version control system for it's
source code
e) every library has to use the Boost License
f) every library has to fulfill a minimum set of directory structure
requirements.
f) Review managers cannot accept library into boost if it fails any of
the above.

Agreed to all of the above.

Post by Robert Ramey via Boost
Of course the Boost web page would have a portion which looks like the
Boost library Incubator. So be it. Actually I've even considered
just adding a page for each current boost library. The library
dropdown would then specify accepted boost libraries, proposed boost
libraries, etc.
Building of all of boost would of just the sequence of "one button"
download build and test for each library.
I was going to put this in a separate post by you started down this path.

Thanks for following up. Yes, I think these are good goals. Is there no
way we can build up momentum around these ideas to be able to move into
that direction ? (And again, please let's not focus on any technical
details how we achieve the above, but first and foremost agree where we
want to go.)

I'd be more than willing to help in any way I can. As Boost.Python
maintainer I'm trying to go down that route anyhow. But I would
appreciate company ! ;-)

Post by Robert Ramey via Boost
Robert Ramey

Stefan

[Vinnie Falco via Boost]

On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost

Documentation has to be standards conforming. That is it would have to
describe libraries in terms of valid expressions rather than implementation

Are you saying that a description of valid expressions is the only
good way to document a library?

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

[Robert Ramey via Boost]

Post by Vinnie Falco via Boost
On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost

Documentation has to be standards conforming. That is it would have to
describe libraries in terms of valid expressions rather than implementation

Are you saying that a description of valid expressions is the only
good way to document a library?

I am.

Post by Vinnie Falco via Boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 8:33 PM, Stefan Seefeld via Boost <

Post by Stefan Seefeld via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.

So instead of substituting a tool, I would like to invite
you to consider a few organizational changes.
Notably, I would like to see the long-stalled modularization process to
be picked up again and be continued (and completed ?).

The original modularization effort called for switching to CMake, but it
was decided that switching to git would be a good first step. I do think
that my proposal is in support of that effort. I'd comment more on your
proposal for something else, but that seems out of scope for this thread.

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

[Stefan Seefeld via Boost]

Post by David Sankel via Boost
On Fri, Jun 16, 2017 at 8:33 PM, Stefan Seefeld via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating

Boost's

Post by David Sankel via Boost
build
system to CMake. I am not speaking for the Boost Program

Committee here,

Post by David Sankel via Boost
but I
plan on bringing this up with them after getting feedback.

So instead of substituting a tool, I would like to invite
you to consider a few organizational changes.
Notably, I would like to see the long-stalled modularization process to
be picked up again and be continued (and completed ?).
The original modularization effort called for switching to CMake, but
it was decided that switching to git would be a good first step. I do
think that my proposal is in support of that effort. I'd comment more
on your proposal for something else, but that seems out of scope for
this thread.

Can you explain how the two are related ? I understand that the current
Boost.Build logic is deficient in its support for modular builds (i.e.,
the ability for individual projects to be built stand-alone). Making
this use-case a top priority (without imposing anything in terms of how
it is implemented) would be useful. But telling everybody what to do
wouldn't.

Stefan

[Robert Ramey via Boost]

Post by David Sankel via Boost
The motivation is simple. CMake is currently the dominant player in the
area of open-source, cross-platform, C++ build-systems.

no dispute here

Post by David Sankel via Boost
* To ease the migration path, both Boost.Build (the current jam-based build
system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each
particular library? Who would re-write and maintain this FindBoost as
the current one is not up the task. Getting this right - or even better
is not a trivial task.

Post by David Sankel via Boost
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be used
instead of the source code.

Another layer of work for "someone" to do and maintain.

Post by David Sankel via Boost
* The style of the 'CMakeLists.txt' files would follow current best
practice.

LOL - good luck on finding a concensus here. Every body and his brother
has his own agenda to make his library "perfect" and to anticipate what
he is sure of are "what users need".

Post by David Sankel via Boost
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.

Your correct on all of the above, but CMake isn't really good enough to
use out of the box. I had to make a bunch of macros to get to work at
all on my environment - it's not an uncommon environment.

Post by David Sankel via Boost
* There would be a list of CMake guidelines that we'd use.

ahhh - another great mailing list topic.

Post by David Sankel via Boost
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies
* We would work with CMake towards eventually taking over maintenance of the
FindBoost module distributed with CMake.

A much bigger job that it would appear.

Post by David Sankel via Boost
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).

My experience is that many boost tests cannot be run with cmake. For
example, I cannot make a CTest test which will be successful on
compile-fail. - Correction I can, but involves some gymnastics about
re-invoking CMake and capturing the result and inverting it and ...

Post by David Sankel via Boost
3. The Boost infrastructure is modified to use CTest for unit testing.

I don't think this would be necessary.

Post by David Sankel via Boost
4. Unit testing functionality is removed from Boost.Build.

I don't think this is necessary either.

Post by David Sankel via Boost
5. Boost.Build is removed.

If CMake is successful, boost build would die on it's own. If you have
to forcibly remove it, you've failed.

Post by David Sankel via Boost
Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.

The problem is that we have problems migrating to CMake BECAUSE we've
got with the other stuff mentioned.

Actually, I believe the real problem is the monolithic build/test design
of boost libraries which inhibits evolution. Boost Build developers
have been very accommodating about adjusting to the particular features
of different libraries. This demonstrates good will, but has given use
with a testing/deployment setup which is very complex.

Post by David Sankel via Boost
One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.

LOL - promote this guy to management !!!!

Post by David Sankel via Boost
Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.

LOL - as someone who has actually built a house, I see the analogy. But
I've alse seen that it doesn't create all the benefits it's expected to
deliver. More central control sounds like a good idea, but it results
in decisions driven more by politics, particular conflicting interests,
excessive conservatism but bureacrats and other entrenched interests.

How is the C++ standard committee working out. Concepts have been in
development for 12 years and only 3 years to go. If Boost went in that
direction we'd still be .... nowhere

I've ridiculed your proposal more than I meant to. (Of course that's
what makes the mailing list fun.) But I realize that it is a sincere
effort attempt to address a real problem. Rather then making this post
boring, I'll follow on with a counter proposal which I think will
address some of your concerns and incorporate your suggestions in a way
which I think is more practical.

Robert Ramey

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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each
particular library? Who would re-write and maintain this FindBoost as the
current one is not up the task. Getting this right - or even better is not
a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is
relatively straightforward. The implementation for the Boost-source version
of this library would look at the COMPONENTS argument and, based on that,
add_subdirectory the source for the particularly requested library. The
CMakeLists.txt file would be author maintained and provide its
corresponding target (e.g. boost::thread).

Post by Robert Ramey via Boost
I see this progressing with several milestones.

Post by David Sankel via Boost
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.

2. The unit tests for all Boost libraries are incorporated into CTest (the

Post by David Sankel via Boost
CMake unit test orchestration tools).

My experience is that many boost tests cannot be run with cmake. For
example, I cannot make a CTest test which will be successful on
compile-fail. - Correction I can, but involves some gymnastics about
re-invoking CMake and capturing the result and inverting it and ...

Thanks for pointing that out. With any build system switch, some things
will be easier and other things will be harder.

Post by Robert Ramey via Boost
3. The Boost infrastructure is modified to use CTest for unit testing.
I don't think this would be necessary.

Perhaps not.

Post by Robert Ramey via Boost
4. Unit testing functionality is removed from Boost.Build.
I don't think this is necessary either.

Likewise.

Post by Robert Ramey via Boost
5. Boost.Build is removed.
If CMake is successful, boost build would die on it's own. If you have to
forcibly remove it, you've failed.

I see your point.

Post by Robert Ramey via Boost
Although there are many other great ideas floating around (e.g.

Post by David Sankel via Boost
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.

The problem is that we have problems migrating to CMake BECAUSE we've got
with the other stuff mentioned.
Actually, I believe the real problem is the monolithic build/test design
of boost libraries which inhibits evolution. Boost Build developers have
been very accommodating about adjusting to the particular features of
different libraries. This demonstrates good will, but has given use with a
testing/deployment setup which is very complex.

Yeah, this is unfortunate, but I don't think this is unfix-able. One step
at a time. First, lets work on getting a decent CMake build. I would love
to have your support here Robert.

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

[P F via Boost]

Post by David Sankel via Boost
On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each
particular library? Who would re-write and maintain this FindBoost as the
current one is not up the task. Getting this right - or even better is not
a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is
relatively straightforward. The implementation for the Boost-source version
of this library would look at the COMPONENTS argument and, based on that,
add_subdirectory the source for the particularly requested library. The
CMakeLists.txt file would be author maintained and provide its
corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is used to find packages installed, it should never go out and build libraries.

If the user wants to add boost to their build(or set of libraries), you would use `add_subdirectory` directly and then override `find_package` to ignore boost packages, and then use the `boost::` alias targets provided.



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

[David Sankel via Boost]

Post by Robert Ramey via Boost

On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <
On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each
particular library? Who would re-write and maintain this FindBoost as

the

Post by Robert Ramey via Boost
current one is not up the task. Getting this right - or even better is

not

Post by Robert Ramey via Boost
a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is
relatively straightforward. The implementation for the Boost-source

version

of this library would look at the COMPONENTS argument and, based on that,
add_subdirectory the source for the particularly requested library. The
CMakeLists.txt file would be author maintained and provide its
corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is
used to find packages installed, it should never go out and build libraries.

I don't know where you get that impression (again, see the video I linked
to earlier). This is, indeed, the only way to write packages that can be
built with already-installed binaries *or* together with the source code of
their dependencies. It is a very important property to have in a build
system for large-scale development.

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

[P F via Boost]

Post by P F via Boost

Post by David Sankel via Boost
On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost

Post by David Sankel via Boost
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each
particular library? Who would re-write and maintain this FindBoost as the
current one is not up the task. Getting this right - or even better is not
a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is
relatively straightforward. The implementation for the Boost-source version
of this library would look at the COMPONENTS argument and, based on that,
add_subdirectory the source for the particularly requested library. The
CMakeLists.txt file would be author maintained and provide its
corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is used to find packages installed, it should never go out and build libraries.
I don't know where you get that impression (again, see the video I linked to earlier).

None of the find modules do this, nor do libraries that provide config cmake. In fact, the video shows a lot of non-standard ways of using cmake, which is what you are proposing we avoid, and I agree with.

Post by P F via Boost
This is, indeed, the only way to write packages that can be built with already-installed binaries or together with the source code of their dependencies.

But you never write packages, rather you ignore the packages, like this:

set(as_subproject Foo)

macro(find_package)
if(NOT "${ARG0}" IN_LIST as_subproject)
_find_package(${ARGV})
endif()
endmacro()

add_subdirectory(Foo)
add_subdirectory(App)

This makes `find_package(Foo)` do nothing as `Foo::Foo` is part of the project. This way projects can be written to support both modular and superproject build without changing the build scripts, and without needing to use `if(NOT TARGET)` hacks.

Post by P F via Boost
It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).


_______________________________________________
Unsubscribe & other changes: h

[Niall Douglas via Boost]

Post by P F via Boost

Post by P F via Boost
It is a very important property to have in a build system for
large-scale development.

It is very important for boost to be able to support
`add_subdirectory` builds. However, hijacking `find_package` to call
`add_subdirectory` is the wrong approach and goes against cmake’s
workflow. The approach I outlined is what is presented in Daniel
Pfeifer’s Effective Cmake talk(although I was aware of this before
Daniel’s talk).

I'm mostly in agreement with Paul here.

You may however also be in agreement too David. Here are some cmake use
cases:

1. I want a library from a Boost release, so find_package(boost 1.60
MODULE COMPONENTS asio REQUIRED), link to boost::asio

2. I am making a new Boost library or I am using Boost trunk source
tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to
boost::asio

3. There is a third use case pre-C++11 Boost libraries can't do which is
to mix some release Boost libraries from find_package with some brought
in by add_subdirectory() from a source tree. You may wish to rule out
supporting that, but equally, a correct cmake implementation should
implement that just fine.


I do agree David that cmake innovation is to be avoided right now. I
have a superb cmake innovation at the library formerly known as
boost-lite and now called quickcpplib because it lets you write state of
the art C++ libraries super-quick by eliminating needing to think about
build or test or tooling or documentation or CI scripting, just supply
the config file and go, the cmake inspects its environment and automates
everything thereafter. It's really amazing. But it also is very
experimental, and insufficiently tested. And it has several serious bugs
I haven't got to fixing yet.

So don't innovate cmake. Just use 100% standard cmake 3.5, and make sure
it is a *good neighbour* to other cmake and is not *anti-social* like
most cmake currently written today. Design the cmake to be usable as
build and discovery drivers by other cmake. This is the key improvement
in cmake 3 - being nice to **any** other cmake.

I'd recommend a minimum of cmake 3.5. You can create header only library
targets and >= 3.5 those work right without bugs. You can create static
and dynamic library targets for those libraries which implement those. I
would personally suggest a Python script which parses Jamfile.v2 and
spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough
using just this.

You just then need to feed everything to the cmake package tooling,
again all 100% cmake 3. And you should be done, no cmake innovation needed.

As Edward pointed out, not everything Boost.Build can do will work in
cmake without cmake innovation. But worry about that after, for end
users of Boost they almost certainly have no need nor want for any of
the stuff beyond already described. Indeed one argument could be "don't
move Boost to cmake, *package* Boost releases with auto-generated cmake
build support". That would make for happy end users.

Niall

[P F via Boost]

Post by Niall Douglas via Boost

Post by P F via Boost

Post by P F via Boost
It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support
`add_subdirectory` builds. However, hijacking `find_package` to call
`add_subdirectory` is the wrong approach and goes against cmake’s
workflow. The approach I outlined is what is presented in Daniel
Pfeifer’s Effective Cmake talk(although I was aware of this before
Daniel’s talk).

I'm mostly in agreement with Paul here.
You may however also be in agreement too David. Here are some cmake use
1. I want a library from a Boost release, so find_package(boost 1.60
MODULE COMPONENTS asio REQUIRED), link to boost::asio

We will need to update cmake so that it finds boost config packages. Or the user can say `find_package(boost_asio)`.

Post by Niall Douglas via Boost
2. I am making a new Boost library or I am using Boost trunk source
tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to
boost::asio

No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.

Post by Niall Douglas via Boost
3. There is a third use case pre-C++11 Boost libraries can't do which is
to mix some release Boost libraries from find_package with some brought
in by add_subdirectory() from a source tree. You may wish to rule out
supporting that, but equally, a correct cmake implementation should
implement that just fine.

There is no reason why that can’t be supported. You only setup `find_package` to ignore the packages that are part of the build and then call `find_package` as you normally would for libraries that aren’t being built.

Post by Niall Douglas via Boost
I do agree David that cmake innovation is to be avoided right now. I
have a superb cmake innovation at the library formerly known as
boost-lite and now called quickcpplib because it lets you write state of
the art C++ libraries super-quick by eliminating needing to think about
build or test or tooling or documentation or CI scripting, just supply
the config file and go, the cmake inspects its environment and automates
everything thereafter. It's really amazing. But it also is very
experimental, and insufficiently tested. And it has several serious bugs
I haven't got to fixing yet.
So don't innovate cmake. Just use 100% standard cmake 3.5, and make sure
it is a *good neighbour* to other cmake and is not *anti-social* like
most cmake currently written today. Design the cmake to be usable as
build and discovery drivers by other cmake. This is the key improvement
in cmake 3 - being nice to **any** other cmake.
I'd recommend a minimum of cmake 3.5.

I agree we should use cmake 3.5 as a baseline, as that is what comes with ubuntu 16.04.

Post by Niall Douglas via Boost
You can create header only library
targets and >= 3.5 those work right without bugs. You can create static
and dynamic library targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the dependencies. Libraries like Hana can “cheat” and export the targets directly to the cmake config package because it has no dependencies. However, for a library like Boost.Fusion the dependencies will need to be listed a third time in the cmake config.

Post by Niall Douglas via Boost
I
would personally suggest a Python script which parses Jamfile.v2 and
spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough
using just this.

We can generate the code with python, which will help with libraries that have lots of dependencies. Although some libraries like Boost.Config is not so simple.

Post by Niall Douglas via Boost
You just then need to feed everything to the cmake package tooling,
again all 100% cmake 3. And you should be done, no cmake innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow, rather it is tool to help reduce the boilerplate needed to provide cmake support in libraries like boost. Otherwise we will have authors create their own set of functions to make the build scripts more maintainable, and then we will lose consistency among boost libraries.

Post by Niall Douglas via Boost
As Edward pointed out, not everything Boost.Build can do will work in
cmake without cmake innovation. But worry about that after, for end
users of Boost they almost certainly have no need nor want for any of
the stuff beyond already described. Indeed one argument could be "don't
move Boost to cmake, *package* Boost releases with auto-generated cmake
build support". That would make for happy end users.

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having pkgconfig would be helpful as well.



_______________________________________________
Unsubscribe & other changes: http://lists

[Niall Douglas via Boost]

Post by P F via Boost

Post by Niall Douglas via Boost
2. I am making a new Boost library or I am using Boost trunk
source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL),
link to boost::asio

No, the `add_subdirectory` is for a superproject. A library will just
call `find_package`(which the superproject will override) to get the
targets.

You mean dependency. Like boost is for end user programs.

A significant minority of end users will not wish to use find_package()
and will strongly prefer to use add_subdirectory(). For example, anyone
on Windows will find add_subdirectory() vastly easier going. Anyone who
currently integrates Boost into their own build and test config will use
add_subdirectory(). Anyone who builds Boost with custom config will use
add_subdirectory().

Well written cmake 3 has no problem allowing that. It's now a build
driver, any external cmake can load it in and ask it for as much or as
little build config as necessary. It's why cmake 3 is so radically
better than cmake 2. Stephen did an amazing job in restructuring cmake
to be reusable by other cmake. CMakeLists.txt is just a library now, to
be consumed by other cmake scripts. If you keep CMakeLists.txt
completely free of custom function and macro baggage, your
CMakeLists.txt becomes extremely reusable and modular for all other cmake.

Post by P F via Boost

Post by Niall Douglas via Boost
You can create header only library targets and >= 3.5 those work
right without bugs. You can create static and dynamic library
targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the
dependencies. Libraries like Hana can “cheat” and export the targets
directly to the cmake config package because it has no dependencies.
However, for a library like Boost.Fusion the dependencies will need
to be listed a third time in the cmake config.

You don't need to generate the cmake config package. cmake generates the
cmake config package using its knowledge of how to build the code. I
don't know where you're getting all this complexity from.

A correct implementation doesn't need anybody to "cheat". It should be
100% modern cmake. If anybody needs to cheat, you've done it wrong.

Post by P F via Boost

Post by Niall Douglas via Boost
I would personally suggest a Python script which parses Jamfile.v2
and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily
enough using just this.

We can generate the code with python, which will help with libraries
that have lots of dependencies. Although some libraries like
Boost.Config is not so simple.

I don't know what you're talking about. cmake tracks dependencies just
fine and can export dependencies into things which consume targets.

Post by P F via Boost

Post by Niall Douglas via Boost
You just then need to feed everything to the cmake package
tooling, again all 100% cmake 3. And you should be done, no cmake
innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow,
rather it is tool to help reduce the boilerplate needed to provide
cmake support in libraries like boost. Otherwise we will have authors
create their own set of functions to make the build scripts more
maintainable, and then we will lose consistency among boost
libraries.

If there is a single custom function in what is implemented, then it's
being done wrong. cmake 3.5 and later comes with substantial runtime
facilities obviating the need for macros and custom functions for most
end users. Just use what comes built into cmake.

I appreciate all the work you've done with the BCM cmake modules. I
respectfully insist that all that is superfluous in a minimum viable
cmake 3.5 implementation. I appreciate what you are saying about the
boilerplate issue, but if you require cmake 3.5 minimum, I do not
believe any significant boilerplate issue should occur.

(Where the difference between mine and your approach stems from is that
cmake is scriptable i.e. you can write programs in cmake which run over
a source tree and do housekeeping using "cmake -P" (sometimes "ctest -S"
is easier/better). These scripts can talk with git and pregenerate
boilerplate that in cmake v2 days would be hidden inside macros. They
can also install themselves into githooks so they regenerate boilerplate
when you do git checkout and so on.

A classic boilerplate to generate is lists of source files to save
CMakeLists.txt having to specify it. Another classic cmake script is for
Appveyor and Travis run per commit as cmake is portable and actually
pretty powerful as a programming language.)


So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to avoid
boilerplate, and keep the CMakeLists.txt etc completely free of any
custom macros or functions. This greatly reduces the learning curve for
library developers, keeps the cmake clean for end users to import into
their cmake, and of course keeps build and configure times very quick.

Niall

[Peter Dimov via Boost]

So tl;dr; I strongly recommend placing all cmake complexity into runnable
scripts which generate .cmake files to be include()d to avoid boilerplate,
and keep the CMakeLists.txt etc completely free of any custom macros or
functions.

Niall, could you please show how an idiomatic CMakeLists.txt file should, in
your opinion, look like, for a run-of-the-mill Boost library? Pick some
existing library to illustrate the point, such as for example System, or
SmartPtr, or even the simplest one, Assert. Or any other, if you prefer.


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

[John Maddock via Boost]

Post by Peter Dimov via Boost

Post by Niall Douglas via Boost
So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to
avoid boilerplate, and keep the CMakeLists.txt etc completely free of
any custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file
should, in your opinion, look like, for a run-of-the-mill Boost
library? Pick some existing library to illustrate the point, such as
for example System, or SmartPtr, or even the simplest one, Assert. Or
any other, if you prefer.

+1

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
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
So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to avoid
boilerplate, and keep the CMakeLists.txt etc completely free of any
custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file
should, in your opinion, look like, for a run-of-the-mill Boost library?
Pick some existing library to illustrate the point, such as for example
System, or SmartPtr, or even the simplest one, Assert. Or any other, if
you prefer.

Sure, though I'm talking really vanilla cmake here. But I guess it will
narrow the discussion by demonstrating idiomatic cmake 3. Too much cmake
2 still kicks around. I really wish cmake would kill off cmake2-isms, as
in, refuse to use them.

According to Jens'
Loading Image..., System
looks the most tractable. I'll see if I can find some hours to do it up,
I can guarantee it won't be today nor tomorrow. Maybe tomorrow night
after the kids are asleep.

Niall

[Peter Dimov via Boost]

Post by Niall Douglas via Boost
According to Jens'
https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System
looks the most tractable.

Not sure how he generated this graph, but if you go by dependencies, Assert
only depends on Config:

C:\Projects\boost-git\boost>dist\bin\boostdep assert
Primary dependencies for assert:

config:
<boost/config.hpp>
from <boost/assert.hpp>

System is

C:\Projects\boost-git\boost>dist\bin\boostdep system
Primary dependencies for system:

assert:
<boost/assert.hpp>
from <boost/system/error_code.hpp>

config:
<boost/config.hpp>
from <boost/system/config.hpp>
<boost/config/abi_prefix.hpp>
from <boost/system/error_code.hpp>
<boost/config/abi_suffix.hpp>
from <boost/system/error_code.hpp>
<boost/config/auto_link.hpp>
from <boost/system/config.hpp>
<boost/config/warning_disable.hpp>
from <boost/system/detail/error_code.ipp>
<boost/cstdint.hpp>
from <boost/system/error_code.hpp>

core:
<boost/noncopyable.hpp>
from <boost/system/error_code.hpp>
<boost/utility/enable_if.hpp>
from <boost/system/error_code.hpp>

predef:
<boost/predef/platform.h>
from <boost/system/config.hpp>

winapi:
<boost/detail/winapi/character_code_conversion.hpp>
from <boost/system/detail/error_code.ipp>
<boost/detail/winapi/error_codes.hpp>
from <boost/system/detail/error_code.ipp>
from <boost/system/windows_error.hpp>
<boost/detail/winapi/error_handling.hpp>
from <boost/system/detail/error_code.ipp>
<boost/detail/winapi/local_memory.hpp>
from <boost/system/detail/local_free_on_destruction.hpp>

but it's a good example on which to demonstrate a build system because it
actually requires building, whereas the simpler libraries are generally
header-only.


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

[Robert Ramey via Boost]

Post by Niall Douglas via Boost

Post by Peter Dimov via Boost

Post by Niall Douglas via Boost
So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to avoid
boilerplate, and keep the CMakeLists.txt etc completely free of any
custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file
should, in your opinion, look like, for a run-of-the-mill Boost library?
Pick some existing library to illustrate the point, such as for example
System, or SmartPtr, or even the simplest one, Assert. Or any other, if
you prefer.

Sure, though I'm talking really vanilla cmake here. But I guess it will
narrow the discussion by demonstrating idiomatic cmake 3. Too much cmake
2 still kicks around. I really wish cmake would kill off cmake2-isms, as
in, refuse to use them.
According to Jens'
https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System
looks the most tractable. I'll see if I can find some hours to do it up,
I can guarantee it won't be today nor tomorrow. Maybe tomorrow night
after the kids are asleep.
Niall

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe
Numerics repo and commented on the CMake files listed there. I think
its pretty simple and canonical usage of CMake as it relates to a Boost
library. The only think I want to change is the existence of some code
in a CMake directory which I'll soon eliminate - but all in all it's
pretty simple. What would be missing from this for it it to meet
expectations of CMake Promotors?

Robert Ramey


_______________________________________________
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 Niall Douglas via Boost
So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to avoid
boilerplate, and keep the CMakeLists.txt etc completely free of any
custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file
should, in your opinion, look like, for a run-of-the-mill Boost library?
Pick some existing library to illustrate the point, such as for example
System, or SmartPtr, or even the simplest one, Assert. Or any other, if
you prefer.

Sure, though I'm talking really vanilla cmake here. But I guess it will
narrow the discussion by demonstrating idiomatic cmake 3. Too much cmake
2 still kicks around. I really wish cmake would kill off cmake2-isms, as
in, refuse to use them.
According to Jens'
https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System
looks the most tractable. I'll see if I can find some hours to do it up,
I can guarantee it won't be today nor tomorrow. Maybe tomorrow night
after the kids are asleep.
Niall

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there. I think its pretty simple and canonical usage of CMake as it relates to a Boost library. The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple. What would be missing from this for it it to meet expectations of CMake Promotors?

* It should not use global `include_directories`.

* Its not necessary to put CMakeLists.txt in every directory with modern cmake.

* There is no installation, and there is no support for `find_package(SafeNumerics)` which can provide a cmake target for downstream user to use. Nor does it provide a cmake target for people to use with `add_subdirectory` either.

* Tests are always built even when the user sets `BUILD_TESTING` to off.

Boost.Hana is much better example of modern cmake.



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

[Robert Ramey via Boost]

Post by P F via Boost

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there. I think its pretty simple and canonical usage of CMake as it relates to a Boost library. The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple. What would be missing from this for it it to meet expectations of CMake Promotors?

* It should not use global `include_directories`.
* Its not necessary to put CMakeLists.txt in every directory with modern cmake.
* There is no installation, and there is no support for `find_package(SafeNumerics)` which can provide a cmake target for downstream user to use. Nor does it provide a cmake target for people to use with `add_subdirectory` either.
* Tests are always built even when the user sets `BUILD_TESTING` to off.
Boost.Hana is much better example of modern cmake.

Thanks for looking at this - the comments above really make me see that
even having spend a lot of time trying to figure out CMake - there is
still a lot I don't know. I have questions on each point above, but
they are not relevant to this thread so I'll move on.

I also looked at Hana usage of CMake. I have to say it's quite
off-putting for a library author to be required to learn a huge amount
of CMake lore and prepare 500 lines of script across several files just
to submit a header only library which.

* only needs to run tests
* users need only point to the header library.

Actually, this example makes bjam look much easier than CMake which I
believe conflicts with the original premise which motivated the proposal.

Robert Ramey


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

[Richard Hodges via Boost]

I fully support any effort to make cmake the de-facto build system for
boost. When used with Ruslo/hunter it is also an excellent package
management system. When used with the polly toolchains (also by ruslo) it
solves all cross-compilation problems.

Cmake's syntax is garbage but it is actively maintained, well supported and
understandable. Bjam on the other hand is indecipherable, undocumented
garbage. If you've ever wondered why more people don't contribute to boost,
it's that.

R

Post by P F via Boost

Post by Robert Ramey via Boost
Hmmm - I would be curious if a CMake enthusiast took a look at the Safe

Numerics repo and commented on the CMake files listed there. I think its
pretty simple and canonical usage of CMake as it relates to a Boost
library. The only think I want to change is the existence of some code in
a CMake directory which I'll soon eliminate - but all in all it's pretty
simple. What would be missing from this for it it to meet expectations of
CMake Promotors?

Post by P F via Boost
* It should not use global `include_directories`.
* Its not necessary to put CMakeLists.txt in every directory with modern

cmake.

Post by P F via Boost
* There is no installation, and there is no support for

`find_package(SafeNumerics)` which can provide a cmake target for
downstream user to use. Nor does it provide a cmake target for people to
use with `add_subdirectory` either.

Post by P F via Boost
* Tests are always built even when the user sets `BUILD_TESTING` to off.
Boost.Hana is much better example of modern cmake.

Thanks for looking at this - the comments above really make me see that
even having spend a lot of time trying to figure out CMake - there is
still a lot I don't know. I have questions on each point above, but
they are not relevant to this thread so I'll move on.
I also looked at Hana usage of CMake. I have to say it's quite
off-putting for a library author to be required to learn a huge amount
of CMake lore and prepare 500 lines of script across several files just
to submit a header only library which.
* only needs to run tests
* users need only point to the header library.
Actually, this example makes bjam look much easier than CMake which I
believe conflicts with the original premise which motivated the proposal.
Robert Ramey
_______________________________________________
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 P F via Boost

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there. I think its pretty simple and canonical usage of CMake as it relates to a Boost library. The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple. What would be missing from this for it it to meet expectations of CMake Promotors?

* It should not use global `include_directories`.
* Its not necessary to put CMakeLists.txt in every directory with modern cmake.
* There is no installation, and there is no support for `find_package(SafeNumerics)` which can provide a cmake target for downstream user to use. Nor does it provide a cmake target for people to use with `add_subdirectory` either.
* Tests are always built even when the user sets `BUILD_TESTING` to off.
Boost.Hana is much better example of modern cmake.

Thanks for looking at this - the comments above really make me see that even having spend a lot of time trying to figure out CMake - there is still a lot I don't know. I have questions on each point above, but they are not relevant to this thread so I'll move on.
I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests
* users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.



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

[Rene Rivera via Boost]

Post by Robert Ramey via Boost

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
Actually, this example makes bjam look much easier than CMake which I

believe conflicts with the original premise which motivated the proposal.
I don’t think its a fair comparison to bjam as its not doing the same
thing. The bjam files in boost for header-only libraries do not
individually install headers or usage requirements.

I think it is at minimum relevant, and mostly fair. The argument for using
an external non-Boost build system, regardless of which one is the current
flavor, is that it is externally supported. And hence no one at Boost needs
to write a bunch of code to make use of it for the Boost use case. But if
there needs to be a significant amount of code in Boost for the build
system the justifications for switching loose considerable appeal. It
doesn't matter where the code is. If it's in individual libraries or
collected in a common Boost module, it's still effort to maintain
comparable to the effort of maintaining b2.

[P F via Boost]

Post by P F via Boost

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.
I think it is at minimum relevant, and mostly fair. The argument for using an external non-Boost build system, regardless of which one is the current flavor, is that it is externally supported. And hence no one at Boost needs to write a bunch of code to make use of it for the Boost use case. But if there needs to be a significant amount of code in Boost for the build system the justifications for switching loose considerable appeal. It doesn't matter where the code is. If it's in individual libraries or collected in a common Boost module, it's still effort to maintain comparable to the effort of maintaining b2.

There is many use cases for switching to cmake. One use case is modular building and to have boost export its usage requirements in the form of pkgconfig or cmake find packages. This can also be done using bjam files as well, but there is work that needs to be done to support this. Of course, the fact that Louis has done the work is not fair to compare with non-existent work. Furthermore, the argument is made that by switching to cmake, boost can take advantage of this larger community support to fulfill this work, instead of letting a decade go by on such unfulfilled requests in bjam.



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

[Rene Rivera via Boost]

Post by Rene Rivera via Boost

Post by Robert Ramey via Boost

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
Actually, this example makes bjam look much easier than CMake which I

believe conflicts with the original premise which motivated the proposal.
I don’t think its a fair comparison to bjam as its not doing the same
thing. The bjam files in boost for header-only libraries do not
individually install headers or usage requirements.

I think it is at minimum relevant, and mostly fair. The argument for using
an external non-Boost build system, regardless of which one is the current
flavor, is that it is externally supported. And hence no one at Boost needs
to write a bunch of code to make use of it for the Boost use case. But if
there needs to be a significant amount of code in Boost for the build
system the justifications for switching loose considerable appeal. It
doesn't matter where the code is. If it's in individual libraries or
collected in a common Boost module, it's still effort to maintain
comparable to the effort of maintaining b2.
There is many use cases for switching to cmake. One use case is modular
building

Concretely define what "modular building" is.

Post by Rene Rivera via Boost
and to have boost export its usage requirements in the form of pkgconfig
or cmake find packages.

Concretely define what it means to support those.

Post by Rene Rivera via Boost
This can also be done using bjam files as well, but there is work that
needs to be done to support this.

True.. But the assumption seems to be that it would easier to do all of the
above with cmake. Which I dispute.

Post by Rene Rivera via Boost
Of course, the fact that Louis has done the work is not fair to compare
with non-existent work.

Perhaps it's not fair to compare work that hasn't been defined sufficiently
to implement for any build system.

Post by Rene Rivera via Boost
Furthermore, the argument is made that by switching to cmake, boost can
take advantage of this larger community support to fulfill this work,
instead of letting a decade go by on such unfulfilled requests in bjam.

It is unfair to blame the build system for requests that are substantially
structural issues with Boost. Issues that would malign any build system
that Boost might use.

[P F via Boost]

Post by Rene Rivera via Boost

Post by Rene Rivera via Boost

Post by Robert Ramey via Boost

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
Actually, this example makes bjam look much easier than CMake which I

believe conflicts with the original premise which motivated the proposal.
I don’t think its a fair comparison to bjam as its not doing the same
thing. The bjam files in boost for header-only libraries do not
individually install headers or usage requirements.

I think it is at minimum relevant, and mostly fair. The argument for using
an external non-Boost build system, regardless of which one is the current
flavor, is that it is externally supported. And hence no one at Boost needs
to write a bunch of code to make use of it for the Boost use case. But if
there needs to be a significant amount of code in Boost for the build
system the justifications for switching loose considerable appeal. It
doesn't matter where the code is. If it's in individual libraries or
collected in a common Boost module, it's still effort to maintain
comparable to the effort of maintaining b2.
There is many use cases for switching to cmake. One use case is modular
building

Concretely define what "modular building" is.

git clone https://github.com/boostorg/build
cd build
./bootstrap.sh
b2 install

cd ..

git clone https://github.com/boostorg/hana
cd hana
b2 install

or with cmake:

git clone https://github.com/boost-cmake/bcm
cd bcm
mkdir build
cd build
cmake ..
cmake --build . --target install

cd ../..

git clone https://github.com/boostorg/hana
cd hana
mkdir build
cd build
cmake ..
cmake --build . --target install

Post by Rene Rivera via Boost

Post by Rene Rivera via Boost
and to have boost export its usage requirements in the form of pkgconfig
or cmake find packages.

Concretely define what it means to support those.

These files would be generated during installation. I am not sure what more detail you are asking?

Post by Rene Rivera via Boost

Post by Rene Rivera via Boost
This can also be done using bjam files as well, but there is work that
needs to be done to support this.

True.. But the assumption seems to be that it would easier to do all of the
above with cmake. Which I dispute.

That is not my assumption, either.

Post by Rene Rivera via Boost

Post by Rene Rivera via Boost
Of course, the fact that Louis has done the work is not fair to compare
with non-existent work.

Perhaps it's not fair to compare work that hasn't been defined sufficiently
to implement for any build system.

Post by Rene Rivera via Boost
Furthermore, the argument is made that by switching to cmake, boost can
take advantage of this larger community support to fulfill this work,
instead of letting a decade go by on such unfulfilled requests in bjam.

It is unfair to blame the build system for requests that are substantially
structural issues with Boost. Issues that would malign any build system
that Boost might use.

Yes, the build is not directly at fault, but if boost moved to cmake, there is a much larger community of people who are familiar with cmake and boost that could help work on these structural changes.



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

[Peter Dimov via Boost]

Post by P F via Boost
git clone https://github.com/boostorg/hana
cd hana
b2 install

Does anybody actually do this? It feels completely alien to me. Where would
the headers go? What will happen to the already existing system Boost
installation? What if I want to uninstall?


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

[Robert Ramey via Boost]

Post by Peter Dimov via Boost

Post by P F via Boost
git clone https://github.com/boostorg/hana
cd hana
b2 install

Does anybody actually do this?

Hmmm - what I do is

git clone https://github.com/boostorg/hana // into my BOOST_ROOT
b2 headers

then I'm done. It never occurred to me that that was alien. Actually,
even now, I can't think of what I would do instead.

It feels completely alien to me. Where

Post by Peter Dimov via Boost
would the headers go? What will happen to the already existing system
Boost installation?

What if I want to uninstall?
I just would delete $BOOST_ROOT/libs/hana

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

[Andrey Semashev via Boost]

Post by Peter Dimov via Boost

Post by P F via Boost
git clone https://github.com/boostorg/hana
cd hana
b2 install

Does anybody actually do this? It feels completely alien to me. Where
would the headers go? What will happen to the already existing system
Boost installation? What if I want to uninstall?

FWIW, my experience with Boost, when I build it for a product, is to
build packages for the system package manager (.deb, .rpm) and then
build the product against those packages. `b2 install` is invoked in the
process of building Boost packages, but not the product.

When working on Boost or with toy projects, I never install and instead
specify include and library dirs pointing to the Boost tree.

`make install` into system directories and similar commands are indeed
discouraged (at least, on Linux) because there is typically no `make
uninstall`. You can install into a separate subtree though, with the
assumption that you can safely delete it afterwards.

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

[P F via Boost]

Post by Peter Dimov via Boost

Post by P F via Boost
git clone https://github.com/boostorg/hana
cd hana
b2 install

Does anybody actually do this? It feels completely alien to me.

I am not sure why it would feel alien, the getting started guide has those same steps:

http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.html#easy-build-and-install

Post by Peter Dimov via Boost
Where would the headers go?

I don’t know what Boost.Build defaults to, but you can control where boost gets installed with the `--prefix` flag.

Post by Peter Dimov via Boost
What will happen to the already existing system Boost installation?

I believe the install rule copies the files, so they would just be replaced.

Post by Peter Dimov via Boost
What if I want to uninstall?

You would delete the directory, unless boost build supports a `b2 uninstall` that is created from the install rule.



_______________________________________________
Unsubscribe & other changes: http

[Robert Ramey via Boost]

Post by P F via Boost

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests
* users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my
system and add the directory to the list of directories to be searched.
What could possible be easier than that.

Post by P F via Boost

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

Hmmm - Now I don't know what the proposal is. I thought it was to
replace bjam. I don't know what else it needs to do. I see CMake as an
alternative way of building and testing libraries. I don't see this
impacting users in any way. I thought I knew what is being proposed but
now I don't think I do. Perhaps this proposal should be something more
specific than "Moving Boost to CMake".

Robert Ramey

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

[P F via Boost]

Post by P F via Boost

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests
* users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.

Much easier to say `cmake --build . --target install` or `install lib` from a package manager then manually figuring out what files need to be copied. Furthermore, this prevents installing the usage requirements, which it is much easier to say `g++ $(pkg-config boost_asio --cflags --libs)` or `target_link_libraries(myLib boost::asio)` then trying to figure out all the compiler and linker flags needed to use asio. A header-only should still provide its usage requirements, because:

* It may require linking in other libraries. Although a library is header-only it may depend on non-header-only libraries. This is the case for Boost.Asio, which needs to link in other libraries.

* A library may change usage requirements in the future. A library could change from header-only to being built, or it could bring in a new dependency that requires linking in a new library. This would affect all downstream libraries, but if the build scripts are using the usage requirements this will require zero changes to the build scripts.

Post by P F via Boost

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

Hmmm - Now I don't know what the proposal is. I thought it was to replace bjam. I don't know what else it needs to do. I see CMake as an alternative way of building and testing libraries. I don't see this impacting users in any way. I thought I knew what is being proposed but now I don't think I do. Perhaps this proposal should be something more specific than "Moving Boost to CMake”.

I believe the proposal was to move to cmake using cmake’s best practices for building, testing, and supporting `find_package`.



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

[Robert Ramey via Boost]

Post by P F via Boost

Hmmm - Now I don't know what the proposal is. I thought it was to replace bjam. I don't know what else it needs to do. I see CMake as an alternative way of building and testing libraries. I don't see this impacting users in any way. I thought I knew what is being proposed but now I don't think I do. Perhaps this proposal should be something more specific than "Moving Boost to CMake”.

I believe the proposal was to move to cmake using cmake’s best practices for building, testing, and supporting `find_package`.

LOL - so it seems that neither one of knows what the proposal actually
is. I think it's time for the promoters of this proposal to step back
and agree on some more specific/concrete proposal that can be discussed
in a productive way - probably on a new thread. Probably with a titile
like one of the following:

a) proposal - Add support for CMake for building boosts and running tests
b) proposal - Add support for CMake to make Boost more user friendly by ...
c) proposal - add your own here ...

And this proposal should start with a succinct goal or motivation

Then describe the actions proposed to support the above. It's helpful
it describes who would undertake which actions - library maintainers,
some Developer, Some other player like the developers of CMake itself, etc.

Some sort of plan/description of how this would would proceed - All at
once - some proposals might not make sense unless applied to all
libraries as a requirement. Others might work as an option for each
library.

Sorry I can't be more specific - but of course I'm not the one making
such a proposal.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: htt

[Stefan Seefeld via Boost]

Hi Robert,

Post by Robert Ramey via Boost

Post by P F via Boost

Post by Robert Ramey via Boost
Hmmm - Now I don't know what the proposal is. I thought it was to
replace bjam. I don't know what else it needs to do. I see CMake as
an alternative way of building and testing libraries. I don't see
this impacting users in any way. I thought I knew what is being
proposed but now I don't think I do. Perhaps this proposal should
be something more specific than "Moving Boost to CMake”.

I believe the proposal was to move to cmake using cmake’s best
practices for building, testing, and supporting `find_package`.

LOL - so it seems that neither one of knows what the proposal actually
is. I think it's time for the promoters of this proposal to step back
and agree on some more specific/concrete proposal that can be
discussed in a productive way - probably on a new thread. Probably
a) proposal - Add support for CMake for building boosts and running tests
b) proposal - Add support for CMake to make Boost more user friendly by ...
c) proposal - add your own here ...

Thanks for trying hard to make this discussion efficient and
constructive. I have followed your suggestion and written my own little
"proposal". It may be lacking in some specifics, though I refrained from
putting too much into it precisely to avoid the discussion once again
being derailed by technical details. Those can all be sorted out easily
once the consensus is there.

It's really sad to see how much effort gets wasted on this list over the
years as ambitious people propose one idea or another, but eventually
get dragged down by the community's inability to "get their act
together" and move in almost any direction, leaving us with the status quo.

Let's keep trying... !

Best,
Stefan

Post by Robert Ramey via Boost
And this proposal should start with a succinct goal or motivation
Then describe the actions proposed to support the above. It's helpful
it describes who would undertake which actions - library maintainers,
some Developer, Some other player like the developers of CMake itself, etc.
Some sort of plan/description of how this would would proceed - All at
once - some proposals might not make sense unless applied to all
libraries as a requirement. Others might work as an option for each
library.
Sorry I can't be more specific - but of course I'm not the one making
such a proposal.
Robert Ramey
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey via Boost]

Post by Stefan Seefeld via Boost
Hi Robert,
It's really sad to see how much effort gets wasted on this list over the
years as ambitious people propose one idea or another, but eventually
get dragged down by the community's inability to "get their act
together" and move in almost any direction, leaving us with the status quo.

LOL - I'm really sympathetic. I often feel the same way.

But if you think about it, it really can't be any other way. We each
have our own set of problems which are "caused" by something or someone
else. The solution is to have that "other" thing get fixed. And this
often ends up with a bunch competing and conflicting ideas which an
never really be resolved. (BTW - it's not just boost it's everywhere).

But we are blessed by self awareness and the ability to engage in
introspection. So we can step back and reset and ask the question what
the hell are we trying to do anyway. This is sometimes helpful.

A different problem is that compromise - which is necessary often takes
the form of including everything - which often kills the whole idea. We
have to work harder to address that. But as the author of two accepted
boost libraries, I can say taht there is no way I could have completed
those tasks without collaboration of those on this list, reviewers,
testers, bug reporters, infrastructure builders etc. Impossible. I don't
know enough - I don't think anyone does. (though I think a goodly number
of us think they do - but I doubt they have actually gotten a library
into boost). So to keep moving forward we have to find a way to keep
this working.

I've sort of inherited the role of mailing list nannie from david
abrahams. I'm sorry about that - I just can't help it.

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

[Robert Ramey via Boost]

Post by P F via Boost

Post by P F via Boost

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests
* users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.

* It may require linking in other libraries. Although a library is header-only it may depend on non-header-only libraries. This is the case for Boost.Asio, which needs to link in other libraries.
* A library may change usage requirements in the future. A library could change from header-only to being built, or it could bring in a new dependency that requires linking in a new library. This would affect all downstream libraries, but if the build scripts are using the usage requirements this will require zero changes to the build scripts.

Hmmm - All of this might help the user (though I doubt it in my case,
not that that matters). But I don't see how it concerns boost library
development. Boost library development is concerned with building
libraries and running tests.

So it sounds like you're interested in making Boost a more satisfying
experience for users of Boost Libraries. A worthy consideration which I
believe many of use would support. I would support a working FindBoost
for example as I use CMake to build ide. Sounds like you have something
in mind like FindBoostSerialization, FindBoostHana, etc. Which might
also be interesting - but it has nothing to do with library development.
FindBoost can be made to work without boost developers doing anything
differently. Why not make a separate project FindBoostxxx and include
all anything you want there. The you don't have convince anyone to do
anything, all you have to do is do it.


_______________________________________________
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

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests
* users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.

* It may require linking in other libraries. Although a library is header-only it may depend on non-header-only libraries. This is the case for Boost.Asio, which needs to link in other libraries.
* A library may change usage requirements in the future. A library could change from header-only to being built, or it could bring in a new dependency that requires linking in a new library. This would affect all downstream libraries, but if the build scripts are using the usage requirements this will require zero changes to the build scripts.

Hmmm - All of this might help the user (though I doubt it in my case, not that that matters).

There is no reason to doubt that user would find this helpful, otherwise users wouldn’t ask for such features. And it may seem like it doesn’t matter at this point for `safe_numerics`, except if you or one the libraries you depend on decide to use a compiled component this will effect both you and your users.

But I don't see how it concerns boost library development. Boost library development is concerned with building libraries and running tests.

And also distribution. Nobody is going to use your library without distribution.

So it sounds like you're interested in making Boost a more satisfying experience for users of Boost Libraries. A worthy consideration which I believe many of use would support. I would support a working FindBoost for example as I use CMake to build ide. Sounds like you have something in mind like FindBoostSerialization, FindBoostHana, etc.

No, something like boost_serialization-config.cmake or boost_hana-config.cmake. Find modules are for third-party libraries that don’t support cmake consumers.

Which might also be interesting - but it has nothing to do with library development.

It does, because each library knows its usage requirements and when they will change, thus each library should provide that to the users.

FindBoost can be made to work without boost developers doing anything differently. Why not make a separate project FindBoostxxx and include all anything you want there. The you don't have convince anyone to do anything, all you have to do is do it.

This does work currently because cmake developers have reversed-engineered the usage requirements, so I can write something like this in cmake:

find_package(Boost)
target_link_libraries(myLib boost::asio)

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.



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

[Robert Ramey via Boost]

Post by P F via Boost

So it sounds like you're interested in making Boost a more satisfying experience for users of Boost Libraries. A worthy consideration which I believe many of use would support. I would support a working FindBoost for example as I use CMake to build ide. Sounds like you have something in mind like FindBoostSerialization, FindBoostHana, etc.

No, something like boost_serialization-config.cmake or boost_hana-config.cmake. Find modules are for third-party libraries that don’t support cmake consumers.

Which might also be interesting - but it has nothing to do with library development.

It does, because each library knows its usage requirements and when they will change, thus each library should provide that to the users.

FindBoost can be made to work without boost developers doing anything differently. Why not make a separate project FindBoostxxx and include all anything you want there. The you don't have convince anyone to do anything, all you have to do is do it.

find_package(Boost)
target_link_libraries(myLib boost::asio)
However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.

So ... you want to add a file boost_serialization-config.cmake to
boost-root/libs/serialiation Right? That's all? I think we've already
acceded to the request that library authors are permitted to add CMake
and other support files to thier directories. So we're done here?

With all due respect, getting a concrete proposal from you is like
pulling teeth. I know you're well meaning, but I need more help here.

Robert Ramey


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

[Rene Rivera via Boost]

Post by P F via Boost
However, when I upgrade boost, I need to upgrade cmake as well. There
really shouldn’t be a coupling between cmake and boost, like that. Instead
each library can provide the cmake configuration, and we can update cmake’s
FindBoost module to look for these configuration files, or the user can
just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is,
IMO, a design and implementation defect of cmake.

Second.. Why not use something like Conan that doesn't care about what
build system your dependencies use and will adjust to the build system you
are using for your product?

[Vinnie Falco via Boost]

On Sun, Jun 18, 2017 at 4:05 PM, Rene Rivera via Boost

Why not use...Conan

Conan is great for killing trolls but for generating Visual Studio
project and solution files (.vcxproj and .sln)? Not so much.

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

[Richard Hodges via Boost]

"Easier integration with cmake" is. It the only concern. There's also
cross-compiling to iOS, android etc etc.

How to do this properly is fully documented in cmake (And provided free of
efort with polly) in bjam it's a total black art.

I am always left with the nagging feeling that something is wrong, because
despite following the instructions on stack overflow, there is no actual
documentation to convince me that all the voodoo in the jam files has
received the correct number of sacrificial virgins.

This is a sorry state of affairs for the worlds most popular c++ library.
It should be easy, no, automatic to include boost. After all, c++ without
boost is like [insert idiom about useless things here].

R

Post by Niall Douglas via Boost

Post by P F via Boost
However, when I upgrade boost, I need to upgrade cmake as well. There
really shouldn’t be a coupling between cmake and boost, like that.

Instead

Post by P F via Boost
each library can provide the cmake configuration, and we can update

cmake’s

Post by P F via Boost
FindBoost module to look for these configuration files, or the user can
just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is,
IMO, a design and implementation defect of cmake.
Second.. Why not use something like Conan that doesn't care about what
build system your dependencies use and will adjust to the build system you
are using for your product?
--
-- 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/

[Rene Rivera via Boost]

Post by Richard Hodges via Boost
This is a sorry state of affairs for the worlds most popular c++ library.
It should be easy, no, automatic to include boost. After all, c++ without
boost is like [insert idiom about useless things here].

I've mentioned this some number of times in the past decade or more.. Using
Boost should be as easy as dropping the source code into your project (and
hence use your build system) and build as needed for your project. And
I've asserted that libraries that don't document how to do that should
consider having a bug.

[Gary Furnish via Boost]

For whatever its worth as a user who sometimes contributes patches to
fix bugs, I don't use the system compiler and instead use scripts to
test different builds of internal code (clang, clang with various
sanitizers and options, different versions of gcc, etc). This is such
a pain with boost build because of the difficulty of automating
building multiple copies with custom compilers and flags with the same
source tree. In cmake this is easy, you just change some command line
flags, something trivial in scripts. In Boost, I think I got it
working once using undocumented features after spending several hours
looking around at docs, source code(!), and stack overflow. I now
automatically just don't use boost
libraries that aren't header only. I would rather rewrite code than
fight with the build process. That is a bad state of affairs.

On Sun, Jun 18, 2017 at 5:15 PM, Richard Hodges via Boost

Post by Richard Hodges via Boost
"Easier integration with cmake" is. It the only concern. There's also
cross-compiling to iOS, android etc etc.
How to do this properly is fully documented in cmake (And provided free of
efort with polly) in bjam it's a total black art.
I am always left with the nagging feeling that something is wrong, because
despite following the instructions on stack overflow, there is no actual
documentation to convince me that all the voodoo in the jam files has
received the correct number of sacrificial virgins.
This is a sorry state of affairs for the worlds most popular c++ library.
It should be easy, no, automatic to include boost. After all, c++ without
boost is like [insert idiom about useless things here].
R

Post by Niall Douglas via Boost

Post by P F via Boost
However, when I upgrade boost, I need to upgrade cmake as well. There
really shouldn’t be a coupling between cmake and boost, like that.

Instead

Post by P F via Boost
each library can provide the cmake configuration, and we can update

cmake’s

Post by P F via Boost
FindBoost module to look for these configuration files, or the user can
just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is,
IMO, a design and implementation defect of cmake.
Second.. Why not use something like Conan that doesn't care about what
build system your dependencies use and will adjust to the build system you
are using for your product?
--
-- 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

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

[P F via Boost]

Post by P F via Boost
However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.
First.. Needing to upgrade cmake to deal with newer releases of Boost is, IMO, a design and implementation defect of cmake.

How is it a defect of cmake? How can cmake know the usage requirements for boost libraries when boost doesn’t make that available?

Post by P F via Boost
Second.. Why not use something like Conan that doesn't care about what build system your dependencies use and will adjust to the build system you are using for your product?

Conan requires adding special function or macros to the cmake that don’t work with standalone cmake. This also makes it not work with other package managers that may want to build the library. We could write conditionals around the conan functions, but then it feels like we are supporting two buildsystems. Hopefully, in the future, conan will fix this so that there is no need for modifications to the cmake file.

Also, cget can work with other build systems as well by providing a cmake file that can translate the cmake toolchain to the other build system. It already provides this support for boost, so you can build boost with:

cget install -X boost https://downloads.sourceforge.net/project/boost/boost/1.64.0/boost_1_64_0.tar.bz2

If we support modular builds like I showed(where I can clone a library and then call `b2 install`), then cget could install libraries modularly:

cget install -X boost boostorg/predef

However, since predef is header-only, you can currently install it like this:

cget install -X header boostorg/predef

Of course, none of this supports the usage requirements. If there is a way to retrieve this information during a build of boost, I can update cget’s boost script to convert this to cmake packages or pkgconfig.






_______________________________________________
Unsubscribe & other changes: ht

[P F via Boost]

Post by Niall Douglas via Boost

Post by P F via Boost

Post by Niall Douglas via Boost
2. I am making a new Boost library or I am using Boost trunk
source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL),
link to boost::asio

No, the `add_subdirectory` is for a superproject. A library will just
call `find_package`(which the superproject will override) to get the
targets.

You mean dependency. Like boost is for end user programs.
A significant minority of end users will not wish to use find_package()
and will strongly prefer to use add_subdirectory(). For example, anyone
on Windows will find add_subdirectory() vastly easier going. Anyone who
currently integrates Boost into their own build and test config will use
add_subdirectory(). Anyone who builds Boost with custom config will use
add_subdirectory().
Well written cmake 3 has no problem allowing that. It's now a build
driver, any external cmake can load it in and ask it for as much or as
little build config as necessary. It's why cmake 3 is so radically
better than cmake 2. Stephen did an amazing job in restructuring cmake
to be reusable by other cmake. CMakeLists.txt is just a library now, to
be consumed by other cmake scripts. If you keep CMakeLists.txt
completely free of custom function and macro baggage, your
CMakeLists.txt becomes extremely reusable and modular for all other cmake.

Yes cmake supports `add_subdirectory` without needing to changing the project scripts. Only the superproject overrides the `find_package`. That is, I write `MyLib` which depends on Foo, like this using `find_package`(ignoring installation for now):

find_package(Foo 2.0 REQUIRED)
add_library(MyLib)
target_link_libraries(MyLib Foo::Foo)

Then if the user would like to build `MyLib` and `Foo` all in the same superprojects they can override `find_package`:

set(as_subproject Foo MyLib)
macro(find_package)
if(NOT "${ARG0}" IN_LIST as_subproject)
_find_package(${ARGV})
endif()
endmacro()
add_subdirectory(Foo)
add_subdirectory(MyLib)
add_subdirectory(App)

In addition you can mix external dependencies and `add_subdirectory`. That is, if Foo depends on zlib, then that could be found with `find_package` instead of being built within the same project.

However, a library should *not* avoid calling `find_package` or rely on strange custom logic(like `if(NOT TARGET)`) in order support `add_subdirectory. Each library should be able to be built independently and then we(or the user) overrides `find_package` to support the superproject builds.

Post by Niall Douglas via Boost

Post by P F via Boost

Post by Niall Douglas via Boost
You can create header only library targets and >= 3.5 those work
right without bugs. You can create static and dynamic library
targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the
dependencies. Libraries like Hana can “cheat” and export the targets
directly to the cmake config package because it has no dependencies.
However, for a library like Boost.Fusion the dependencies will need
to be listed a third time in the cmake config.

You don't need to generate the cmake config package. cmake generates the
cmake config package using its knowledge of how to build the code. I
don't know where you're getting all this complexity from.
A correct implementation doesn't need anybody to "cheat". It should be
100% modern cmake. If anybody needs to cheat, you've done it wrong.

Cmake generates the export targets, however, if a dependency comes from another imported target, cmake will not create those imported targets. Instead they need to be defined with a call to `find_package`. However, in a config cmake package you will use `find_dependency` instead(which is almost the same except it it forwards the correct parameters for EXACT, QUIET and REQUIRED which were passed to the original `find_package` call). So if `MyLib` depends on `Foo`, then the cmake pakcage config would be written like this:

include(CMakeFindDependencyMacro)
find_dependency(Foo 2.0)
include("${CMAKE_CURRENT_LIST_DIR}/MyLibTargets.cmake”)

The `find_dependency` is necessary because `MyLib` depends on `Foo::Foo` which would be left undefined without a call to `find_package`(or `find_dependency` in this case). This allows the dependencies and packages to be relocatable, which is important.

However, in the case of a library like Hana, that has no dependencies, there is no need to call `find_dependency. Essentially, it would look like this:

include("${CMAKE_CURRENT_LIST_DIR}/HanaTargets.cmake”)

So instead of having cmake write the targets to a separate file, instead the targets can be written directly to the `HanaConfig.cmake`. This is what I meant by “cheat”. What Hana does is entirely correct and appropriate.

Post by Niall Douglas via Boost

Post by P F via Boost

Post by Niall Douglas via Boost
I would personally suggest a Python script which parses Jamfile.v2
and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily
enough using just this.

We can generate the code with python, which will help with libraries
that have lots of dependencies. Although some libraries like
Boost.Config is not so simple.

I don't know what you're talking about. cmake tracks dependencies just
fine and can export dependencies into things which consume targets.

For every `find_package` used in cmake(that is not a build-dependency) there needs to be a corresponding `find_dependency` call in the cmake package config file.

Also, Boost.Config tests are generated from *.ipp files, which is different than other boost libraries, and it adds a little more complexity.

Post by Niall Douglas via Boost

Post by P F via Boost

Post by Niall Douglas via Boost
You just then need to feed everything to the cmake package
tooling, again all 100% cmake 3. And you should be done, no cmake
innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow,
rather it is tool to help reduce the boilerplate needed to provide
cmake support in libraries like boost. Otherwise we will have authors
create their own set of functions to make the build scripts more
maintainable, and then we will lose consistency among boost
libraries.

If there is a single custom function in what is implemented, then it's
being done wrong. cmake 3.5 and later comes with substantial runtime
facilities obviating the need for macros and custom functions for most
end users. Just use what comes built into cmake.
I appreciate all the work you've done with the BCM cmake modules. I
respectfully insist that all that is superfluous in a minimum viable
cmake 3.5 implementation. I appreciate what you are saying about the
boilerplate issue, but if you require cmake 3.5 minimum, I do not
believe any significant boilerplate issue should occur.

I disagree, there is still quite a bit of boilerplate. Also, the modules support additional things like pkgconfig.

Post by Niall Douglas via Boost
(Where the difference between mine and your approach stems from is that
cmake is scriptable i.e. you can write programs in cmake which run over
a source tree and do housekeeping using "cmake -P" (sometimes "ctest -S"
is easier/better). These scripts can talk with git and pregenerate
boilerplate that in cmake v2 days would be hidden inside macros. They
can also install themselves into githooks so they regenerate boilerplate
when you do git checkout and so on.

I think code generation on each commit is the wrong way to do this.

Post by Niall Douglas via Boost
A classic boilerplate to generate is lists of source files to save
CMakeLists.txt having to specify it.

That is not something BCM tries to do. Authors can decide how they want to manage that. Instead BCM tries to handle the boilerplate between synchronizing the dependencies in the build, cmake package config, linking, and pkgconfig. It can also help ensure that libraries correctly alias the target to easily support superproject builds.

Post by Niall Douglas via Boost
Another classic cmake script is for
Appveyor and Travis run per commit as cmake is portable and actually
pretty powerful as a programming language.)
So tl;dr; I strongly recommend placing all cmake complexity into
runnable scripts which generate .cmake files to be include()d to avoid
boilerplate, and keep the CMakeLists.txt etc completely free of any
custom macros or functions. This greatly reduces the learning curve for
library developers, keeps the cmake clean for end users to import into
their cmake, and of course keeps build and configure times very quick.
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.b

[Robert Ramey via Boost]

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

I was going to make an more elaborate counter proposal here but got
carried away on another thread an included it there.

Why don't you cut down your proposal to something simpler and actually
doable. What would you think of the following:

Proposal:

a) Permit Boost Library authors to sprinkle CMakeList.txt files
whereever they want in the directories of their own libraries.

b) Create a directory in boost-root/tools/.... where CMake enthusiasts
can put their macros and any other needed stuff of their choosing.

This would yield the following benefits.

a) This should be enough for any library author to implement CMake
support for his library.

b) it's non-intrusive. It would not conflict with anything currently in
boost.

c) it would permit "Boost/CMake" to evolve at it's own pace without
causing havoc among any innocent victims.

d) This would be very simple to do - I don't know that it even requires
any decision by anyone at all. I've included CMakeList.txt files in the
serialization library for years and no one has objected. I think you
should just encourage library authors to do this. You might offer to
help them if you want by providing useful macros, a working FindBoost,
documentation with suggestions and instructions. I made the Boost
Library Incubator with large sections of advice for aspiring boost
library authors. I didn't recommend Bjam support as it's not needed for
review (and I actually don't like bjam). I recommended CMake and spend
a good amount of text explaining it in the context of making a boost
like library. I learned that a) CMake isn't nearly as good as people
think it is and b) It can be made to work. If you want to improve and
maintain that section, I would be very, very pleased to hand it over to you.

Just to summarize:

a) Encourge library authors to include CMakeLists.txt file in their
directories. If some committee wants to complain about it, we'll deal
with it then.

b) Create helpful information for library authors that want to do this.
I've got a good place for you to do it.

Sit back and watch your idea catch fire

Robert Ramey


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

[David Sankel via Boost]

On Fri, Jun 16, 2017 at 9:45 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost
I was going to make an more elaborate counter proposal here but got
carried away on another thread an included it there.
Why don't you cut down your proposal to something simpler and actually
doable.

I don't think what I'm suggesting is overly bold. We can do this thing.
[Reforming large code bases is my day job]

Post by Robert Ramey via Boost
a) Permit Boost Library authors to sprinkle CMakeList.txt files whereever
they want in the directories of their own libraries.

To be clear, this is already allowed.

Post by Robert Ramey via Boost
b) Create a directory in boost-root/tools/.... where CMake enthusiasts can
put their macros and any other needed stuff of their choosing.
This would yield the following benefits.
a) This should be enough for any library author to implement CMake support
for his library.
b) it's non-intrusive. It would not conflict with anything currently in
boost.
c) it would permit "Boost/CMake" to evolve at it's own pace without
causing havoc among any innocent victims.
d) This would be very simple to do - I don't know that it even requires
any decision by anyone at all. I've included CMakeList.txt files in the
serialization library for years and no one has objected. I think you
should just encourage library authors to do this. You might offer to help
them if you want by providing useful macros, a working FindBoost,
documentation with suggestions and instructions. I made the Boost Library
Incubator with large sections of advice for aspiring boost library
authors. I didn't recommend Bjam support as it's not needed for review
(and I actually don't like bjam). I recommended CMake and spend a good
amount of text explaining it in the context of making a boost like
library. I learned that a) CMake isn't nearly as good as people think it
is and b) It can be made to work. If you want to improve and maintain that
section, I would be very, very pleased to hand it over to you.
a) Encourge library authors to include CMakeLists.txt file in their
directories. If some committee wants to complain about it, we'll deal with
it then.
b) Create helpful information for library authors that want to do this.
I've got a good place for you to do it.
Sit back and watch your idea catch fire

:) I don't dislike this idea, but I think moving all of Boost to CMake is
a big step that we *can* and *should* do. The first milestone is the most
important one in my proposal.

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

[Robert Ramey via Boost]

Post by David Sankel via Boost

Post by Robert Ramey via Boost
a) Encourge library authors to include CMakeLists.txt file in their
directories. If some committee wants to complain about it, we'll deal with
it then.
b) Create helpful information for library authors that want to do this.
I've got a good place for you to do it.
Sit back and watch your idea catch fire

:) I don't dislike this idea, but I think moving all of Boost to CMake is
a big step that we *can* and *should* do. The first milestone is the most
important one in my proposal.

Hmm - I'm not sure what milestone you're referring to. I'll just
repeat: Start doing the above two items. I believe there is already
good start at disseminating useful information in the cmake section of
the incubator. You evaluate and critisize the CMakeList.txt file in the
safe numerics library. You can either enhance or replace that. As far
as I can I'm the only one who has actually done anything to make CMake
useful to boost. But I'm certainly happy to see anyone else make an effort.

I spent a fair amount of effort studying CMake with an eye to making
boost work better. Here is my summary of it.

a) CMake build libraries - Since most of boost is header only there's
not really much for CMake to do.

b) CMake to specify tests. This is the main thing that CMake can do.

c) CTest sets up running the tests. Not much to after b is done.

d) CDash - this interested me a lot and I spend mearsureable time with
it. It embodied the idea that I would like that users run tests on
their own systems for the libraries they use and results would be
uploaded to a common area. Bjam does this only with all of boost at
once. Since I looked at this we now have appveror, travis etc. which
may fulfill some of that role. (though in my opinion they are another
example of half-assed build tools). CDash is pretty much a hack and
would require considerable investment of effort to even approach the
information that the boost build test matrix holds. (and even the boost
build test matrix needs a serious upgrade in my opinion).

e) Find boost. This is for users of Boost (not authors) who use CMake
on their own systems to import boost libraries. It doesn't require that
boost use CMake. Fixing FindBoost might be nice - but it doesn't really
have anything to do with boost itself.

So for most boost libraries the only role of CMake would be to build,
run and post tests. That's it. I'd like to see it done though. I
would like to see uses run tests of the libraries that they use on their
own systems and post the results to a common area. But this is way in
the future. For now all you have to do is a) and b) above. And half of
that is already done.

The boost library incubator is on git hub and open to PRs to any section
including the information as it relates to Cmake on boost. The safe
numerics library is also on git hub and open to PR s to the
CMakeList.txt files in the package.

What more do you need to get started?

Robert Ramey

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

[Stefan Seefeld via Boost]

Post by David Sankel via Boost
On Fri, Jun 16, 2017 at 9:45 PM, Robert Ramey via Boost <

Post by Robert Ramey via Boost
a) Encourge library authors to include CMakeLists.txt file in their
directories. If some committee wants to complain about it, we'll deal with
it then.
b) Create helpful information for library authors that want to do this.
I've got a good place for you to do it.
Sit back and watch your idea catch fire

:) I don't dislike this idea, but I think moving all of Boost to CMake is
a big step that we *can* and *should* do.

I disagree. While I applaud your intentions, I think you would do a huge
disservice to project maintainers: As Boost.Python maintainer I'm
already receiving lots of bug reports about issues with the build
system, most of which I have no clue how to resolve, given Boost.Build's
often cited complexities. If you add support for a second build system
that I don't know anything about, how likely do you think I am to be
able to help my user base ?

What we need is for project maintainers to be able to pick tools *they*
understand so they can operate more autonomously. (And for avoidance of
doubt: If their user base asks for a specific tool, it's of course fine
for them to decide to support that. But it shouldn't be for any central
Boost authority to decide top-down what is best for all projects !)

Thanks,
Stefan

[P F via Boost]

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.
The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based on
Google trends graphs and discussions with others at the conferences I attend
(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater C++
community and making Boost more accessible would be of great utility.
* To ease the migration path, both Boost.Build (the current jam-based build
system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake.

Find modules are only for third-party libraries. Boost should only provide config packages, and then update cmake’s FindBoost to use boost’s cmake config packages.

Post by David Sankel via Boost
A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be used
instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.

Although, somewhat outdated, and incorrect in places, this repo has an example of building boost with proper cmake support:

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

However, I find this brittle and error-prone. Here’s an example of cmake for Boost.Fusion:

https://github.com/boost-cmake/boost-cmake/blob/master/listsfiles/libs/fusion/CMakeLists.txt

This doesn’t even handle fusion's dependencies, and it is a little incorrect.

I have been working on cmake modules to handle this, but I am in the process of refactoring it, here:

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

One way the Boost.Fusion could be written is like this using the modules to generate the cmake package config:

bcm_setup_version(VERSION ${BOOST_VERSION})

find_package(boost_config)
find_package(boost_core)
find_package(boost_function_types)
find_package(boost_functional)
find_package(boost_mpl)
find_package(boost_preprocessor)
find_package(boost_static_assert)
find_package(boost_tuple)
find_package(boost_type_traits)
find_package(boost_typeof)
find_package(boost_utility)

add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

target_link_libraries(boost_fusion INTERFACE
boost::config
boost::core
boost::function_types
boost::functional
boost::mpl
boost::preprocessor
boost::static_assert
boost::tuple
boost::type_traits
boost::typeof
boost::utility
)

bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion
DEPENDS
PACKAGE boost_config
PACKAGE boost_core
PACKAGE boost_function_types
PACKAGE boost_functional
PACKAGE boost_mpl
PACKAGE boost_preprocessor
PACKAGE boost_static_assert
PACKAGE boost_tuple
PACKAGE boost_type_traits
PACKAGE boost_typeof
PACKAGE boost_utility
)

However, with dependencies this is not maintainable. But perhaps a `bcm_boost_depends` can handle this, like this:

bcm_setup_version(VERSION ${BOOST_VERSION})

add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

bcm_boost_depends(boost_fusion INTERFACE
boost_config
boost_core
boost_function_types
boost_functional
boost_mpl
boost_preprocessor
boost_static_assert
boost_tuple
boost_type_traits
boost_typeof
boost_utility
)

bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion)

This is the direction I would like to take the modules, and I think this is much more maintainable. Code repetition is not good, and just boost has innovated C++, I see no reason it couldn’t help innovate cmake. Especially, since these modules do no stray from what standard cmake does.

Post by David Sankel via Boost
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require all the libraries to be built together. I don’t think libraries individually can provide components.

Post by David Sankel via Boost
* We would work with CMake towards eventually taking over maintenance of the
FindBoost module distributed with CMake.

Each library should provide its own package of the form `find_package(boost_*)`, and the we can update the cmake to search for those components first and then fallback on the guessing games.

Post by David Sankel via Boost
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution

Sans circular dependencies. As libraries which have circular dependencies will always have to be built with the entire distribution, but hopefully having modularing building might push authors to fix the cycles.

Post by David Sankel via Boost
and all the 'FindBoost' functionality mentioned above would be
incorporated.

Wouldn’t we need to update `FindBoost` in cmake so this would work?

Post by David Sankel via Boost
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.
Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.
One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.
Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.
Thanks for your consideration.
-- David Sankel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes

[David Sankel via Boost]

Post by David Sankel via Boost

On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.
The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based

on

Google trends graphs and discussions with others at the conferences I

attend

(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater

C++

community and making Boost more accessible would be of great utility.
* To ease the migration path, both Boost.Build (the current jam-based

build

system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake.

Find modules are only for third-party libraries. Boost should only provide
config packages, and then update cmake’s FindBoost to use boost’s cmake
config packages.

A CMake-based
application
could point to it and, instead of using the system Boost libraries,

Boost

targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be

used

instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.

Although, somewhat outdated, and incorrect in places, this repo has an
https://github.com/boost-cmake/boost-cmake
However, I find this brittle and error-prone. Here’s an example of cmake
https://github.com/boost-cmake/boost-cmake/blob/master/
listsfiles/libs/fusion/CMakeLists.txt
This doesn’t even handle fusion's dependencies, and it is a little incorrect.
I have been working on cmake modules to handle this, but I am in the
https://github.com/boost-cmake/bcm
One way the Boost.Fusion could be written is like this using the modules
bcm_setup_version(VERSION ${BOOST_VERSION})
find_package(boost_config)
find_package(boost_core)
find_package(boost_function_types)
find_package(boost_functional)
find_package(boost_mpl)
find_package(boost_preprocessor)
find_package(boost_static_assert)
find_package(boost_tuple)
find_package(boost_type_traits)
find_package(boost_typeof)
find_package(boost_utility)
add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)
target_link_libraries(boost_fusion INTERFACE
boost::config
boost::core
boost::function_types
boost::functional
boost::mpl
boost::preprocessor
boost::static_assert
boost::tuple
boost::type_traits
boost::typeof
boost::utility
)
bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion
DEPENDS
PACKAGE boost_config
PACKAGE boost_core
PACKAGE boost_function_types
PACKAGE boost_functional
PACKAGE boost_mpl
PACKAGE boost_preprocessor
PACKAGE boost_static_assert
PACKAGE boost_tuple
PACKAGE boost_type_traits
PACKAGE boost_typeof
PACKAGE boost_utility
)
However, with dependencies this is not maintainable. But perhaps a
bcm_setup_version(VERSION ${BOOST_VERSION})
add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)
bcm_boost_depends(boost_fusion INTERFACE
boost_config
boost_core
boost_function_types
boost_functional
boost_mpl
boost_preprocessor
boost_static_assert
boost_tuple
boost_type_traits
boost_typeof
boost_utility
)
bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion)
This is the direction I would like to take the modules, and I think this
is much more maintainable. Code repetition is not good, and just boost has
innovated C++, I see no reason it couldn’t help innovate cmake. Especially,
since these modules do no stray from what standard cmake does.

I'd rather not tie cmakification of Boost to innovating CMake, at least not
at the outset. I think you have some good ideas in your bcm library, but
I'd like to see wider industry adoption before switching Boost to them. I
don't like the risk involved.

Post by David Sankel via Boost

* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require
all the libraries to be built together. I don’t think libraries
individually can provide components.

It doesn't require all the libraries to be built together and, yes,
libraries can provide components. See this talk:

Post by David Sankel via Boost

* We would work with CMake towards eventually taking over maintenance of

the

FindBoost module distributed with CMake.

Each library should provide its own package of the form
`find_package(boost_*)`, and the we can update the cmake to search for
those components first and then fallback on the guessing games.

Hrm. Maybe.

Post by David Sankel via Boost

I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution

Sans circular dependencies. As libraries which have circular dependencies
will always have to be built with the entire distribution, but hopefully
having modularing building might push authors to fix the cycles.

Yeah, sans circular dependencies.

Post by David Sankel via Boost

and all the 'FindBoost' functionality mentioned above would be
incorporated.

Wouldn’t we need to update `FindBoost` in cmake so this would work?

No, I don't think so.

_______________________________________________
Unsubscribe & other changes: http:

[P F via Boost]

Post by P F via Boost

Post by David Sankel via Boost
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require all the libraries to be built together. I don’t think libraries individually can provide components.
It doesn't require all the libraries to be built together and, yes, libraries can provide components. See this http://youtu.be/3eH4hMKl7XE http://youtu.be/3eH4hMKl7XE

Sorry, that was worded poorly. Rather a library can not add additional components to a previously installed library(not without some strange hackery).



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

[David Sankel via Boost]

Post by David Sankel via Boost

Post by P F via Boost

On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require
all the libraries to be built together. I don’t think libraries
individually can provide components.

It doesn't require all the libraries to be built together and, yes,
libraries can provide components. See this talk: https://www.youtube.com/
watch?v=3eH4hMKl7XE
Sorry, that was worded poorly. Rather a library can not add additional
components to a previously installed library(not without some strange
hackery).

Ah, I see what you mean now. I didn't mean to imply we should support that
use case.

_______________________________________________
Unsubscribe & other chan

[Peter Dimov via Boost]

Post by P F via Boost
bcm_setup_version(VERSION ${BOOST_VERSION})

When I see this my first thought is always "where do the bcm_ macros come
from"?

Ideally, we should strive for libraries to work standalone.


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

[P F via Boost]

Post by P F via Boost
bcm_setup_version(VERSION ${BOOST_VERSION})

When I see this my first thought is always "where do the bcm_ macros come from”?
Ideally, we should strive for libraries to work standalone.

Sorry, I skipped over that part. The bcm_ macros are another boost library that would be installed and found with `find_package`. I was just trying to transform the code I linked to, but ideally, it would written like this:

find_package(BCM)
find_package(boost_config) # Use main boost version version

bcm_setup_version(VERSION ${BOOST_CONFIG_VERSION})

add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

bcm_boost_depends(boost_fusion INTERFACE
boost_config
boost_core
boost_function_types
boost_functional
boost_mpl
boost_preprocessor
boost_static_assert
boost_tuple
boost_type_traits
boost_typeof
boost_utility
)

bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion)

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

_______________________________________________
Unsubscribe & other cha

[Klemens Morgenstern via Boost]

I am dead set against that. CMake is inferior to boost.build and it's
only popular for the lack of alternatives. Boost.build could be one (I
use it in my projects outside of boost) but it a steep learning curve
and is not distributed outside of boost. But even the syntax is less
horrible than the CMake one in my opinion.

I do think CMake is broken in it's core, because it doesn't build but
create a description (i.e. makefile or similar). And in order to change
that I have to clear the cache and reconstruct it. Boost.build on the
other hand works like a charm if I have a proper build description and
write `b2 toolset=gcc toolset=msvc` - it will build both and test on
both without any conflicts. I think we should definitely keep
boost.build around, if only to have it's concepts (as in meta-targets)
in a working build-system. I also don't think CMake will be around
forever, it's a deficient solution. As ist boost.build, but boost.build
gets the job done for boost. I don't see the point of moving from one
deficient tool to a worse one, just because everybody seems to be using it.

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.
The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based on
Google trends graphs and discussions with others at the conferences I attend
(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater C++
community and making Boost more accessible would be of great utility.
* To ease the migration path, both Boost.Build (the current jam-based build
system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
'FindBoost' module that is distributed with CMake. A CMake-based
application
could point to it and, instead of using the system Boost libraries, Boost
targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
replacement for the 'FindBoost' module distributed with CMake. The
behavior
is similar to the previous bullet, except the built binaries would be used
instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
We'd resist the temptation to write macros which replace the core CMake
functions. There would be repetition in the files, to be sure, but I
think we
should avoid attempting to innovate CMake. I've seen this fail on many
occasions and would like to keep our goal focused, at this point, on
migrating Boost to CMake. In the future we could revisit this.
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
'find_package(Boost...)' to discover their Boost dependencies.
* We would work with CMake towards eventually taking over maintenance of the
FindBoost module distributed with CMake.
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.
Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.
One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.
Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.
Thanks for your consideration.
-- David Sankel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[P F via Boost]

I am dead set against that. CMake is inferior to boost.build and it's only popular for the lack of alternatives. Boost.build could be one (I use it in my projects outside of boost) but it a steep learning curve and is not distributed outside of boost. But even the syntax is less horrible than the CMake one in my opinion.

CMake's syntax is verbose, which makes it much more friendly to pickup. Bjam’s syntax is too terse with too many weird quirks that most authors just copy and paste code.

I do think CMake is broken in it's core, because it doesn't build but create a description (i.e. makefile or similar). And in order to change that I have to clear the cache and reconstruct it. Boost.build on the other hand works like a charm if I have a proper build description and write `b2 toolset=gcc toolset=msvc` - it will build both and test on both without any conflicts.

You would just create two separate build trees for each configuration. I don’t see how that makes CMake broken.

I think we should definitely keep boost.build around, if only to have it's concepts (as in meta-targets) in a working build-system. I also don't think CMake will be around forever, it's a deficient solution.

A lot of autotools projects are moving to cmake. I don’t see them moving the Boost.Build. Boost.Build doesn’t have the support that cmake does.

As ist boost.build, but boost.build gets the job done for boost. I don't see the point of moving from one deficient tool to a worse one, just because everybody seems to be using it.

I don’t think it does get the job done. Some boost libraries do more extensive testing in cmake than in the Boost.Build because it doesn’t get the job done. Some libraries have auto-generated tests and files because Boost.Build doesn’t get the job done. Even more so, downstream projects have to reverse engineer the dependencies because Boost.Build doesn’t get the job done.



_______________________________________________
Unsubscribe & other changes: http

[Steven Watanabe via Boost]

AMDG

Post by P F via Boost
I don’t think it does get the job done. Some boost libraries do more extensive testing in cmake than in the Boost.Build because it doesn’t get the job done.

Are you talking about things like this:
https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake

Boost.Build implementation:
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

In Christ,
Steven Watanabe


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

[Vinnie Falco via Boost]

On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost

Post by Steven Watanabe via Boost
https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

Hey!!! I might have to steal that :)

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

[Peter Dimov via Boost]

Post by Vinnie Falco via Boost
On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost

Post by Steven Watanabe via Boost
https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

Hey!!! I might have to steal that :)

Might not we all?

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

[Rene Rivera via Boost]

On Sat, Jun 17, 2017 at 9:45 AM, Peter Dimov via Boost <

Post by Peter Dimov via Boost

Post by Vinnie Falco via Boost
On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost

Post by Steven Watanabe via Boost
https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

Hey!!! I might have to steal that :)

Might not we all?

I guess Paul is right.. B2 syntax is terse. But not too terse ;-)

[Vinnie Falco via Boost]

On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost

Post by Steven Watanabe via Boost
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

We have the sources to bjam why can't we just turn this into a one-line rule?

For example, this says that test.cpp should compile:

compile test.cpp

Can we just have

compile-header test.hpp

And have bjam add the bits to define a main() and include test.hpp for us?

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

[Steven Watanabe via Boost]

AMDG

Post by Vinnie Falco via Boost
On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost

Post by Steven Watanabe via Boost
https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

We have the sources to bjam why can't we just turn this into a one-line rule?
compile test.cpp
Can we just have
compile-header test.hpp
And have bjam add the bits to define a main() and include test.hpp for us?

It's certainly possible if there's enough demand.
The main issue for generalization is the test
target name. It needs to
a) be human readable and writable,
b) not be excessively long, and
c) not cause collisions (headers with the same
name in different directories are normal)

In Christ,
Steven Watanabe


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

[Louis Dionne via Boost]

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the
discussions in this thread, it seems like people are getting caught into the
trap of discussing the specifics of how we would implement a proper
CMakeLists.txt file and so on. I think this is completely missing the point.
What we need is to acknowledge that the current situation of supporting
Boost.Build only is a major pain for our users since they (1) most likely
don't use it in house, (2) don't know it, (3) don't want to learn it, and
(4) have to deal with it whether they like it or not. If you go into the
wild, you'll find
- people that don't use Boost because it's too hard to build or integrate
into their build system
- people that only use the header-only libraries because they don't have to
build them and/or because the integration is as simple as changing a header
path
- people that build properly but are tired of maintaining their bridge
between Boost.Build and their own system

This, I think is our real problem. The discussion is not about whether it's
better for Boost library developers to use Boost.Build, CMake, or Bazel for
that matter. It's about what's best our users, who GREATLY outnumber us. And
given that CMake is the de-facto standard, the best way to help our users is
to provide easy integration of Boost with that build system (however that
happens).

It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.

That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).

The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake. This
would not make Boost easier to build, but once built and installed, it would
at least be trivial to use _properly_ from a CMake project. This does not
require changing the build system of existing libraries to CMake.

Regards,
Louis




--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695717.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Raffi Enficiaud via Boost]

Post by Louis Dionne via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the
discussions in this thread, it seems like people are getting caught into the
trap of discussing the specifics of how we would implement a proper
CMakeLists.txt file and so on. I think this is completely missing the point.
What we need is to acknowledge that the current situation of supporting
Boost.Build only is a major pain for our users since they (1) most likely
don't use it in house, (2) don't know it, (3) don't want to learn it, and
(4) have to deal with it whether they like it or not. If you go into the
wild, you'll find
- people that don't use Boost because it's too hard to build or integrate
into their build system
- people that only use the header-only libraries because they don't have to
build them and/or because the integration is as simple as changing a header
path
- people that build properly but are tired of maintaining their bridge
between Boost.Build and their own system
This, I think is our real problem. The discussion is not about whether it's
better for Boost library developers to use Boost.Build, CMake, or Bazel for
that matter. It's about what's best our users, who GREATLY outnumber us. And
given that CMake is the de-facto standard, the best way to help our users is
to provide easy integration of Boost with that build system (however that
happens).
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.
That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake. This
would not make Boost easier to build, but once built and installed, it would
at least be trivial to use _properly_ from a CMake project. This does not
require changing the build system of existing libraries to CMake.
Regards,
Louis

I am totally for a better support of CMake, and what you suggest is ok
to me. However (and since the topic is already very huge), maybe I
missed some elements. This is usually what I do:

1. I build boost using bjam and install it in some folder
2. in "my_other_project" that uses cmake, I just specify
-DBOOST_ROOT=/myboostinstallfolder and everything works like a charm.

This is something I always did and it always worked, I do not see any
strong limitation on it. So when you say "properly", does it mean the
support the user gets in case of failure? or for maintaining his own
configuration for having FindBoost running ok?

Does this means that, all the problems we are facing and trying to solve
in this thread are due to the proper integration of some static or
shared libraries installed in some path, and users not being able to
import those in their own cmake project? (because FindBoost does an ok
job, as does FindGoogleTest, FindCUDA, etc etc).

Thanks,
Raffi


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

[Louis Dionne via Boost]

Post by Raffi Enficiaud via Boost
I am totally for a better support of CMake, and what you suggest is ok
to me. However (and since the topic is already very huge), maybe I
1. I build boost using bjam and install it in some folder
2. in "my_other_project" that uses cmake, I just specify
-DBOOST_ROOT=/myboostinstallfolder and everything works like a charm.
This is something I always did and it always worked, I do not see any
strong limitation on it. So when you say "properly", does it mean the
support the user gets in case of failure? or for maintaining his own
configuration for having FindBoost running ok?

No, what I mean is that you don't have working per-library targets with the
vanilla FindBoost module. You only have some targets for non-header-only
libraries, and the Boost::boost target for including the headers. So you
can't do something like:

find_package(Boost COMPONENTS interprocess)
target_link_libraries(my_exe PRIVATE Boost::interprocess)

and have it "just work". Instead, you'll have to create the proper target
yourself by doing something like:

# Create a proper Boost::interprocess target
find_package(Boost COMPONENTS date_time)
add_library(boost_interprocess INTERFACE)
add_library(Boost::interprocess ALIAS boost_interprocess)
target_link_libraries(boost_interprocess INTERFACE Boost::boost
Boost::date_time)
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")
target_link_libraries(boost_interprocess INTERFACE -lrt)
endif()

# Now link against it
target_link_libraries(my_exe PRIVATE Boost::interprocess)

This is actually taken from a CMakeLists.txt I use at work. Note that I'm
not picking on Boost.IPC, it's just the example I had at hand.

Louis




--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695739.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Edward Diener via Boost]

Post by Louis Dionne via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the
discussions in this thread, it seems like people are getting caught into the
trap of discussing the specifics of how we would implement a proper
CMakeLists.txt file and so on. I think this is completely missing the point.
What we need is to acknowledge that the current situation of supporting
Boost.Build only is a major pain for our users since they (1) most likely
don't use it in house, (2) don't know it, (3) don't want to learn it, and
(4) have to deal with it whether they like it or not. If you go into the
wild, you'll find
- people that don't use Boost because it's too hard to build or integrate
into their build system
- people that only use the header-only libraries because they don't have to
build them and/or because the integration is as simple as changing a header
path
- people that build properly but are tired of maintaining their bridge
between Boost.Build and their own system
This, I think is our real problem. The discussion is not about whether it's
better for Boost library developers to use Boost.Build, CMake, or Bazel for
that matter. It's about what's best our users, who GREATLY outnumber us. And
given that CMake is the de-facto standard, the best way to help our users is
to provide easy integration of Boost with that build system (however that
happens).
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.
That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module
entails ? For a header-only library ? For a built library ? For running
tests ? For creating documentation ? Along with some sort of decent
explanation of what is going on in each situation.

Post by Louis Dionne via Boost
This
would not make Boost easier to build, but once built and installed, it would
at least be trivial to use _properly_ from a CMake project. This does not
require changing the build system of existing libraries to CMake.
Regards,
Louis

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

[Peter Dimov via Boost]

Post by Louis Dionne via Boost
The proposal is to add to the Boost library guidelines the requirement
that a XYZConfig.cmake module be provided with the installation of any
Boost.XYZ library. This module would simply export the proper CMake
targets, which would solve the problem of integrating Boost with a
CMake-based build system and would remove the need for the custom
FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module entails
? For a header-only library ? For a built library ? For running tests ?
For creating documentation ? Along with some sort of decent explanation of
what is going on in each situation.

Yes, I would also like to know. Please give your suggested guideline. What
should library authors be encouraged/required to actually do?


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

[Glen Fernandes via Boost]

On Sun, Jun 18, 2017 at 4:03 PM, Edward Diener via Boost

Please give a specific example of what this XYZConfig.cmake module entails ?
For a header-only library ? For a built library ? For running tests ? For
creating documentation ? Along with some sort of decent explanation of what
is going on in each situation.

+1. I'm interested in the [typical] Boost header-only library case:
- The CMakeLists.txt for building its tests
- The .cmake file for locating the library
- The consumption of the library in a user's CMakeLists

I have a guess ( based on my fairly basic usage of CMake) that at
least #3 there should be simple (i.e. would it involve more than
adding to include_directories or target_include_directories?).

Glen

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

[Niall Douglas via Boost]

Post by Glen Fernandes via Boost
On Sun, Jun 18, 2017 at 4:03 PM, Edward Diener via Boost

Please give a specific example of what this XYZConfig.cmake module entails ?
For a header-only library ? For a built library ? For running tests ? For
creating documentation ? Along with some sort of decent explanation of what
is going on in each situation.

- The CMakeLists.txt for building its tests
- The .cmake file for locating the library
- The consumption of the library in a user's CMakeLists
I have a guess ( based on my fairly basic usage of CMake) that at
least #3 there should be simple (i.e. would it involve more than
adding to include_directories or target_include_directories?).

I have a patchset for Boost 1.64 in motion implementing a bare minimum
viable cmake 3. No custom macros nor functions. It's out for review off
list right now, but it will include an example of header only library.

Niall

[Peter Dimov via Boost]

Post by Glen Fernandes via Boost
- The CMakeLists.txt for building its tests
- The .cmake file for locating the library
- The consumption of the library in a user's CMakeLists
I have a guess ( based on my fairly basic usage of CMake) that at least #3
there should be simple (i.e. would it involve more than adding to
include_directories or target_include_directories?).

In principle, neither should be needed, only target_link_libraries( target
Boost::Whatever ). The usage requirements of Boost::Whatever would add the
include directory (and its dependencies would transitively add their include
directories.)


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

[Mateusz Loskot via Boost]

Post by Louis Dionne via Boost
The proposal is to add to the Boost library guidelines the requirement
that a XYZConfig.cmake module be provided with the installation of any
Boost.XYZ library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build
system and would remove the need for the custom FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module entails ?
For a header-only library ?

AFAIU, the advantage of using CMake exported targets for header-only
libraries is [1]:

"one can "link" to a (header-only) INTERFACE library using
target_link_libraries and get the include
directories added to compilation of one's own sources."

[1] https://cmake.org/pipermail/cmake-developers/2015-July/025680.html

For a built library ?

Feature-wise, similar to the above, but with completing linker arguments.

Best regards,

[P F via Boost]

Post by Louis Dionne via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the
discussions in this thread, it seems like people are getting caught into the
trap of discussing the specifics of how we would implement a proper
CMakeLists.txt file and so on. I think this is completely missing the point.
What we need is to acknowledge that the current situation of supporting
Boost.Build only is a major pain for our users since they (1) most likely
don't use it in house, (2) don't know it, (3) don't want to learn it, and
(4) have to deal with it whether they like it or not. If you go into the
wild, you'll find
- people that don't use Boost because it's too hard to build or integrate
into their build system
- people that only use the header-only libraries because they don't have to
build them and/or because the integration is as simple as changing a header
path
- people that build properly but are tired of maintaining their bridge
between Boost.Build and their own system
This, I think is our real problem. The discussion is not about whether it's
better for Boost library developers to use Boost.Build, CMake, or Bazel for
that matter. It's about what's best our users, who GREATLY outnumber us. And
given that CMake is the de-facto standard, the best way to help our users is
to provide easy integration of Boost with that build system (however that
happens).
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.
That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation.

I think Daniel Pfeifer “Effective CMake” talk gives a good overview how this can be done in cmake. Of course, doing this outside of cmake would be a little more work, but probably could be built-in to boost build(which can handle the heavy lifting).



_______________________________________________
Unsubscribe & other changes: htt

[Vinnie Falco via Boost]

On Sun, Jun 18, 2017 at 12:05 PM, Louis Dionne via Boost

Post by Louis Dionne via Boost
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority.

You mean the minority that spend countless hours per week maintaining
Boost, including libraries they did not author?

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

[Louis Dionne via Boost]

Post by Vinnie Falco via Boost
On Sun, Jun 18, 2017 at 12:05 PM, Louis Dionne via Boost
&lt;

Post by Louis Dionne via Boost
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority.

You mean the minority that spend countless hours per week maintaining
Boost, including libraries they did not author?

Yes. I'm not making any statement about the value of the contributions of an
individual or group of individuals to Boost (in particular, I'm not trying
to diminish anyone's contribution). I'm stating that some people have a
biased view that is not shared by the majority of people using Boost, and
this group of people is over represented on this list. If we're not careful
about that, we could make decisions that are bad for our users (and I think
we sometimes do).




--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695733.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Daniel James via Boost]

Post by Louis Dionne via Boost
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.

One difference with git modularization is that there was a lot of
support for it. And I don't think it was a roaring success.

Post by Louis Dionne via Boost
That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake. This
would not make Boost easier to build, but once built and installed, it would
at least be trivial to use _properly_ from a CMake project. This does not
require changing the build system of existing libraries to CMake.

This seems more sensible, but adding a guideline won't do anything.
Someone needs to volunteer to create the pull requests, and maintain
it in the future.

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

[P F via Boost]

Post by Daniel James via Boost

Post by Louis Dionne via Boost
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.

One difference with git modularization is that there was a lot of
support for it. And I don't think it was a roaring success.

There is a lot support for this in the larger C++ community. I remember at C+Now2016, about 95% of the attendees raised their hands in support of moving to cmake. Among the boost developers the support may not be quite as high. I think it would be good to get some solid data on this.



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

[Louis Dionne via Boost]

Post by Louis Dionne via Boost

Post by Louis Dionne via Boost
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any

Boost.XYZ

Post by Louis Dionne via Boost
library. This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build

system

Post by Louis Dionne via Boost
and would remove the need for the custom FindBoost support in CMake.

This

Post by Louis Dionne via Boost
would not make Boost easier to build, but once built and installed, it

would

Post by Louis Dionne via Boost
at least be trivial to use _properly_ from a CMake project. This does

not

Post by Louis Dionne via Boost
require changing the build system of existing libraries to CMake.

This seems more sensible, but adding a guideline won't do anything.
Someone needs to volunteer to create the pull requests, and maintain
it in the future.

Sorry, the original message should have said "add to the Boost library
REQUIREMENTS", not GUIDELINES. Requirements are actionable, guidelines are
not.

Louis




--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695742.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[P F via Boost]

Post by Louis Dionne via Boost

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the
discussions in this thread, it seems like people are getting caught into the
trap of discussing the specifics of how we would implement a proper
CMakeLists.txt file and so on. I think this is completely missing the point.
What we need is to acknowledge that the current situation of supporting
Boost.Build only is a major pain for our users since they (1) most likely
don't use it in house, (2) don't know it, (3) don't want to learn it, and
(4) have to deal with it whether they like it or not. If you go into the
wild, you'll find
- people that don't use Boost because it's too hard to build or integrate
into their build system
- people that only use the header-only libraries because they don't have to
build them and/or because the integration is as simple as changing a header
path
- people that build properly but are tired of maintaining their bridge
between Boost.Build and their own system
This, I think is our real problem. The discussion is not about whether it's
better for Boost library developers to use Boost.Build, CMake, or Bazel for
that matter. It's about what's best our users, who GREATLY outnumber us. And
given that CMake is the de-facto standard, the best way to help our users is
to provide easy integration of Boost with that build system (however that
happens).
It is also worth noting that people on this list that oppose vocally are
Boost library developers or folks with deep involvement/knowledge of
Boost.Build, which is a very small minority. This has become clear through
years of anecdotal evidence (such as speaking to people at conferences).
Based on this and previous failed attempts, I think it is unlikely that
we'll be able to make a decision based solely on discussion on this list,
and my opinion is that a top-down decision is required to make something
(anything) happen, like for the Git modularization.
That being said, I would like to propose an alternative route that is softer
than David's to see what people think. I still think that David's proposal
is better, but if that was uncontroversial enough, perhaps this could get
the ball rolling and we could go from there (and provide some relief to our
users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that
a XYZConfig.cmake module be provided with the installation of any Boost.XYZ
library.

Or rather `boost_xyz-config.cmake` for each Boost.Xyz. The reason for this is:

* The `-config.cmake` is case-insensitive
* it matches the library name(ie find_package(boost_system) and find_library(LIB boost_system))
* It follows the boost guildelines to have all files be lowercase

Post by Louis Dionne via Boost
This module would simply export the proper CMake targets, which
would solve the problem of integrating Boost with a CMake-based build system
and would remove the need for the custom FindBoost support in CMake. This
would not make Boost easier to build, but once built and installed, it would
at least be trivial to use _properly_ from a CMake project. This does not
require changing the build system of existing libraries to CMake.

Although I am not following the proposal. Are you suggesting that the Boost.Build generate these files? Or that we move to cmake to build and test, and we require the libraries to install the config files?

Post by Louis Dionne via Boost
Regards,
Louis
--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695717.html
Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Louis Dionne via Boost]

Post by P F via Boost
* The `-config.cmake` is case-insensitive
* it matches the library name(ie find_package(boost_system) and
find_library(LIB boost_system))
* It follows the boost guildelines to have all files be lowercase

Sure, anything's fine by me. As long as we settle on something that's
blessed by CMake experts (e.g. Stephen Kelly and Daniel Pfeifer), I'm on
board.

Post by P F via Boost
Although I am not following the proposal. Are you suggesting that the
Boost.Build generate these files? Or that we move to cmake to build and
test, and we require the libraries to install the config files?

I intentionally left it unspecified how these files would be generated and
installed. All that I care (in the scope of this sub-proposal) is that they
are installed when Boost is installed, so that I can use the targets from
CMake without jumping through hoops or relying on the incomplete FindBoost
package provided with CMake.



--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695736.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[P F via Boost]

Post by Louis Dionne via Boost

Post by P F via Boost
Or rather `boost_xyz-config.cmake` for each Boost.Xyz. The reason for this
* The `-config.cmake` is case-insensitive
* it matches the library name(ie find_package(boost_system) and
find_library(LIB boost_system))
* It follows the boost guildelines to have all files be lowercase

Sure, anything's fine by me. As long as we settle on something that's
blessed by CMake experts (e.g. Stephen Kelly and Daniel Pfeifer), I'm on
board.

Post by P F via Boost
Although I am not following the proposal. Are you suggesting that the
Boost.Build generate these files? Or that we move to cmake to build and
test, and we require the libraries to install the config files?

I intentionally left it unspecified how these files would be generated and
installed. All that I care (in the scope of this sub-proposal) is that they
are installed when Boost is installed, so that I can use the targets from
CMake without jumping through hoops or relying on the incomplete FindBoost
package provided with CMake.

But the question is who will implement it, and how will they be tested?


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

[Peter Dimov via Boost]

Post by Louis Dionne via Boost
I intentionally left it unspecified how these files would be generated and
installed.

What is actionable in your proposal then? What is it you suggest we - by
this I mean library developers, who the library guidelines target - actually
do?


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

[Louis Dionne via Boost]

Post by Peter Dimov via Boost

Post by Louis Dionne via Boost
I intentionally left it unspecified how these files would be generated and
installed.

What is actionable in your proposal then? What is it you suggest we - by
this I mean library developers, who the library guidelines target - actually
do?

What's actionable is that if the Boost library requirements contain this,
you'll have to go implement it in your own library. There you go, now we've
taken care of all the maintained libraries. For the unmaintained ones, we
have a community maintenance team that has commit privilege to them, and I'm
sure we can find people to submit pull requests. Let me get the ball
rolling; I volunteer to do the work for Boost.MPL and Boost.ConceptCheck.
There's now 8 libraries remaining:

[ ] Boost.DateTime
[ ] Boost.DisjointSet
[ ] Boost.DynamicBitset
[ ] Boost.Format
[ ] Boost.Function
[ ] Boost.Logic
[ ] Boost.PropertyMap
[ ] Boost.Signals (which is deprecated)
[ ] Boost.Tokenizer
[x] Boost.MPL
[x] Boost.ConceptCheck

Louis




--
View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695623p4695741.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Peter Dimov via Boost]

Post by Louis Dionne via Boost
What's actionable is that if the Boost library requirements contain this,
you'll have to go implement it in your own library.

Contain what?

What do I need to implement?

How?

I already asked Niall this, I'm asking you. Pick one representative
header-only library and one representative non-header-only library as
examples and show us what needs to be done. Please.


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

[P F via Boost]

Post by Louis Dionne via Boost

Post by Peter Dimov via Boost

Post by Louis Dionne via Boost
I intentionally left it unspecified how these files would be generated

and

Post by Peter Dimov via Boost

Post by Louis Dionne via Boost
installed.

What is actionable in your proposal then? What is it you suggest we - by
this I mean library developers, who the library guidelines target - actually
do?

What's actionable is that if the Boost library requirements contain this,
you'll have to go implement it in your own library. There you go, now we've
taken care of all the maintained libraries. For the unmaintained ones, we
have a community maintenance team that has commit privilege to them, and I'm
sure we can find people to submit pull requests. Let me get the ball
rolling; I volunteer to do the work for Boost.MPL and Boost.ConceptCheck.
[ ] Boost.DateTime
[ ] Boost.DisjointSet
[ ] Boost.DynamicBitset
[ ] Boost.Format
[ ] Boost.Function
[ ] Boost.Logic
[ ] Boost.PropertyMap
[ ] Boost.Signals (which is deprecated)
[ ] Boost.Tokenizer
[x] Boost.MPL
[x] Boost.ConceptCheck

How are you planning to add the support? I can definitely help with this, as for most libraries it should be just massaging boostdep output to create the cmake files, but I would like to coordinate your approach.

And the next question is how do we maintain these? That is how do we tests these to make sure that they are correct for the boost release?



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

[Vicente J. Botet Escriba via Boost]

Post by David Sankel via Boost
Howdy all,
This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.
<snip>
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
each Boost library can be built in isolation or with the entire
distribution
and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.

What will be wrong supporting two build systems, at least for a while?

Best,
Vicente

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