Proposal for moving Boost to CMake

classic Classic list List threaded Threaded
141 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

Proposal for moving Boost to CMake

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
<[hidden email]> wrote:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/2017 7:44 PM, David Sankel via Boost wrote:

> 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.

>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> * 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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi David,

On 16.06.2017 19:44, David Sankel via Boost wrote:
> 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

--

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/17 4:48 PM, Vinnie Falco via Boost wrote:

> On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
> <[hidden email]> wrote:
>> 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

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.

> 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.
>
> Thanks
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/17 4:44 PM, David Sankel via Boost wrote:

> The motivation is simple. CMake is currently the dominant player in the
> area of open-source, cross-platform, C++ build-systems.

no dispute here

> * 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.

> * 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.

> * 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".

>    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.

> * There would be a list of CMake guidelines that we'd use.

ahhh - another great mailing list topic.

> * 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.
>
> 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 ...

> 3. The Boost infrastructure is modified to use CTest for unit testing.

I don't think this would be necessary.

> 4. Unit testing functionality is removed from Boost.Build.

I don't think this is necessary either.

> 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.

> 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.

> 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 !!!!

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/17 5:30 PM, Niall Douglas via Boost wrote:
> 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.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:
> Hi David,
>
> On 16.06.2017 19:44, David Sankel via Boost wrote:
  The problem isn't a technical one, it's systemic / organisational.

Agreed.
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 16.06.2017 21:26, Robert Ramey via Boost wrote:
> On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:

[...]

>> 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 :-) ).

>
> 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.")

> 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.

> 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.

> 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...

> 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

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").

>
> 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.

>
> 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 ! ;-)

> Robert Ramey
        Stefan

--

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost
<[hidden email]> wrote:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/2017 8:30 PM, Niall Douglas via Boost wrote:

>> * 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.

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

>
> Niall
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 7:48 PM, Vinnie Falco via Boost <
[hidden email]> wrote:

> On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
> <[hidden email]> wrote:
> > 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
>

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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 8:27 PM, Edward Diener via Boost <
[hidden email]> wrote:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 8:30 PM, Niall Douglas via Boost <
[hidden email]> wrote:

> > * 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.
>

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


> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 8:33 PM, Stefan Seefeld via Boost <
[hidden email]> wrote:

>
> On 16.06.2017 19:44, David Sankel via Boost wrote:
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 8:38 PM, Robert Ramey via Boost <
[hidden email]> wrote:

> On 6/16/17 4:48 PM, Vinnie Falco via Boost wrote:
>
>> On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
>> <[hidden email]> wrote:
>>
>>> 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
>>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/16/17 7:25 PM, Vinnie Falco via Boost wrote:
> On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost
> <[hidden email]> wrote:
>> 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.

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for moving Boost to CMake

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <
[hidden email]> wrote:

> On 6/16/17 4:44 PM, David Sankel via Boost wrote:
>
>> * 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).



> 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 ...


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


>
>
> 3. The Boost infrastructure is modified to use CTest for unit testing.
>>
>
> I don't think this would be necessary.


Perhaps not.


>
>
> 4. Unit testing functionality is removed from Boost.Build.
>>
>
> I don't think this is necessary either.
>

Likewise.


>
> 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.


>
>
> 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.


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
1234 ... 8