[boost] Proposal for moving Boost to CMake
David Sankel via Boost
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
<bo...@lists.boost.org> wrote:
> 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
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
Edward Diener via Boost
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.
Niall Douglas via Boost
> '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.
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/
Stefan Seefeld via Boost
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.
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...
Robert Ramey via Boost
> On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
> <bo...@lists.boost.org> 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
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?
would have to be a transition whereby both are supported. Eventually
this would sort itself out.
Robert Ramey via Boost
> The motivation is simple. CMake is currently the dominant player in the
> area of open-source, cross-platform, C++ build-systems.
> * 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.
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.
> * The style of the 'CMakeLists.txt' files would follow current best
> practice.
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.
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.
> * Boost libraries should be buildable in isolation and use
> 'find_package(Boost...)' to discover their Boost dependencies
> 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).
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.
> 4. Unit testing functionality is removed from Boost.Build.
> 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.
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.
> 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.
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
Robert Ramey 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
> It would be the least the Steering Committee could do to put that wrong
> right and officially say sorry.
the whole episode.
Robert Ramey
Robert Ramey via Boost
> Hi David,
>
> On 16.06.2017 19:44, David Sankel via Boost wrote:
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
> 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...
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
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. 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
Stefan Seefeld via Boost
> 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).
>
> 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.
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.
> 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 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.
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
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.
>
> 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.
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
--
...ich hab' noch einen Koffer in Berlin...
Vinnie Falco via Boost
<bo...@lists.boost.org> wrote:
> Documentation has to be standards conforming. That is it would have to
> describe libraries in terms of valid expressions rather than implementation
good way to document a library?
Edward Diener 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.
happened is completely wrong.
>
> Niall
David Sankel via Boost
bo...@lists.boost.org> wrote:
> On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost
> <bo...@lists.boost.org> 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
>
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.
David Sankel via Boost
bo...@lists.boost.org> 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.
>
> 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.
>
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.
not your time was wasted". This is a significant time and probably monetary
investment, something worthy of discussion *before* the work is done.
David Sankel via Boost
bo...@lists.boost.org> 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.
>
David Sankel via Boost
bo...@lists.boost.org> 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.
>
> 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 ?).
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.
David Sankel via Boost
bo...@lists.boost.org> 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
>> <bo...@lists.boost.org> 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.
Robert Ramey via Boost
> On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost
> <bo...@lists.boost.org> 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?
David Sankel via Boost
bo...@lists.boost.org> 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.
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 ...
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.
>
>
> 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.
at a time. First, lets work on getting a decent CMake build. I would love
to have your support here Robert.
P F via Boost
> On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <bo...@lists.boost.org> 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.
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 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.
> * 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.
> * 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.
>
> 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.
> and all the 'FindBoost' functionality mentioned above would be
> incorporated.
Wouldn’t we need to update `FindBoost` in cmake so this would work?
P F via Boost
> On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <bo...@lists.boost.org> wrote:
>
> On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <
> bo...@lists.boost.org> 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).
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.
David Sankel via Boost
bo...@lists.boost.org> wrote:
> 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.
[Reforming large code bases is my day job]
> 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.
>
a big step that we *can* and *should* do. The first milestone is the most
important one in my proposal.
David Sankel via Boost
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.
> > * 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
>
> > * 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.
>
> >
> > 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.
>
> > 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.
David Sankel via Boost
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.
P F via Boost
> On Jun 16, 2017, at 11:51 PM, David Sankel <cam...@gmail.com> wrote:
>
>
>
> On Sat, Jun 17, 2017 at 12:27 AM, P F <pfu...@yahoo.com <mailto:pfu...@yahoo.com>> wrote:
>
> > On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> wrote:
>
>
>
> > * 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.
>
>
Sorry, that was worded poorly. Rather a library can not add additional components to a previously installed library(not without some strange hackery).
David Sankel via Boost
>
> On Jun 16, 2017, at 11:51 PM, David Sankel <cam...@gmail.com> wrote:
>
>
>
> On Sat, Jun 17, 2017 at 12:27 AM, P F <pfu...@yahoo.com> wrote:
>
>>
>> > On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <
>> bo...@lists.boost.org> wrote:
>>
>>
>
>> > * 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.
P F via Boost
> On Jun 16, 2017, at 11:54 PM, David Sankel <cam...@gmail.com> wrote:
>
> On Sat, Jun 17, 2017 at 12:34 AM, P F <pfu...@yahoo.com <mailto:pfu...@yahoo.com>> wrote:
>
> > On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> wrote:
> >
> > On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <
> > bo...@lists.boost.org <mailto:bo...@lists.boost.org>> 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).
>
> 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.
> 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.
> 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).
Robert Ramey via Boost
>> 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
>
>
> :) 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.
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
Klemens Morgenstern via Boost
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.
Am 17.06.2017 um 01:44 schrieb 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.
> '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.
> 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.
> * Boost libraries should be buildable in isolation and use
> 'find_package(Boost...)' to discover their Boost dependencies.
> FindBoost module distributed with CMake.
>
>
> 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
> incorporated.
Niall Douglas via Boost
>> 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
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Stefan Seefeld via Boost
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,
--
...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld via Boost
> On Fri, Jun 16, 2017 at 8:33 PM, Stefan Seefeld via Boost
> <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> 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.
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
--
...ich hab' noch einen Koffer in Berlin...
Peter Dimov 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.
P F via Boost
> On Jun 17, 2017, at 5:23 AM, Niall Douglas via Boost <bo...@lists.boost.org> wrote:
>
>>> 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
We will need to update cmake so that it finds boost config packages. Or the user can say `find_package(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
No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.
>
> 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.
>
>
> 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.
> 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.
> 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.
>
> 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.
>
> 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.
P F via Boost
> On Jun 17, 2017, at 6:08 AM, Peter Dimov via Boost <bo...@lists.boost.org> wrote:
>
> P F wrote:
>
>> 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)
>
Edward Diener via Boost
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.
P F via Boost
> On Jun 17, 2017, at 2:11 AM, Klemens Morgenstern via Boost <bo...@lists.boost.org> wrote:
>
> 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.
Steven Watanabe via Boost
On 06/17/2017 07:57 AM, P F via Boost wrote:
>
> 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
Vinnie Falco via Boost
<bo...@lists.boost.org> wrote:
> 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
Peter Dimov via Boost
> On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost
> <bo...@lists.boost.org> wrote:
> > 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
>
> Hey!!! I might have to steal that :)
Rene Rivera via Boost
bo...@lists.boost.org> wrote:
> Vinnie Falco wrote:
>
>> On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost
>> <bo...@lists.boost.org> wrote:
>> > 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
>>
>> Hey!!! I might have to steal that :)
>>
>
> Might not we all?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Niall Douglas via Boost
>> 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.
>> 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.
>> 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.
>> 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
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Vinnie Falco 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?
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.
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.
John Maddock via Boost
On 17/06/2017 17:51, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>
>> 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.
---
This email has been checked for viruses by AVG.
http://www.avg.com
Niall Douglas via Boost
>> 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.
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
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Peter Dimov via Boost
> According to Jens'
> https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System
> looks the most tractable.
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.
Robert Ramey 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
>
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
P F via Boost
> On Jun 17, 2017, at 11:30 AM, Niall Douglas via Boost <bo...@lists.boost.org> wrote:
>
>>> 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.
>
>>> 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.
>
>>> 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.
>
>>> 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.
>
> (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.
>
> 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.
P F via Boost
* 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.
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?
>
> * 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.
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
Richard Hodges via Boost
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
On Sat, 17 Jun 2017 at 22:10, Robert Ramey via Boost <bo...@lists.boost.org>
wrote:
Steven Watanabe via Boost
On 06/17/2017 10:45 AM, Vinnie Falco via Boost wrote:
> On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost
> <bo...@lists.boost.org> wrote:
>> Boost.Build implementation:
>> 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?
>
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
P F via Boost
> On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <bo...@lists.boost.org> wrote:
>
> On 6/17/17 11:42 AM, P F via Boost wrote:
>>> 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.
Rene Rivera via Boost
wrote:
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.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
P F via Boost
> On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafi...@gmail.com> wrote:
>
> On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> wrote:
>
> > On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> wrote:
> >
> > 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.
Robert Ramey 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.
>> 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
Rene Rivera via Boost
>
> On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafi...@gmail.com> wrote:
>
> On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <bo...@lists.boost.org>
> wrote:
>
>>
>> > On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
>> bo...@lists.boost.org> wrote:
>> >
>> > 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.
> 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.
> 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.
> 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.
> 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.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
P F via Boost
> On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost <bo...@lists.boost.org> wrote:
>
> On 6/17/17 8:55 PM, P F via Boost wrote:
>>> 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.
>
>>> 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`.
P F via Boost
> On Jun 18, 2017, at 9:24 AM, Rene Rivera via Boost <bo...@lists.boost.org> wrote:
>
> On Sun, Jun 18, 2017 at 12:03 AM, P F <pfu...@yahoo.com <mailto:pfu...@yahoo.com>> wrote:
>
>>
>> On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafi...@gmail.com> wrote:
>>
>> On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <bo...@lists.boost.org>
>> wrote:
>>
>>>
>>>> On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
>>> bo...@lists.boost.org> wrote:
>>>>
>>>> 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
>
>
>> 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?
>
>
>> 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.
>
>
>> 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.
>
>
>> 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.
Peter Dimov via Boost
the headers go? What will happen to the already existing system Boost
installation? What if I want to uninstall?
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 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
Robert Ramey via Boost
>
>> On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost <bo...@lists.boost.org> wrote:
>>
>> On 6/17/17 8:55 PM, P F via Boost wrote:
>>>> 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.
>
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.
Robert Ramey via Boost
> "P F" wrote:
>
>> git clone https://github.com/boostorg/hana
>> cd hana
>> b2 install
>
> Does anybody actually do this?
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
> would the headers go? What will happen to the already existing system
> Boost installation?
What if I want to uninstall?
Stefan Seefeld via Boost
On 18.06.2017 11:20, Robert Ramey via Boost wrote:
> On 6/18/17 7:30 AM, P F via Boost wrote:
>
>>> 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 ...
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
>
> 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost
--
...ich hab' noch einen Koffer in Berlin...
Robert Ramey 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.
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.
Andrey Semashev via Boost
> "P F" wrote:
>
>> 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?
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.
Louis Dionne 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.
Raffi Enficiaud via Boost
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
Edward Diener via Boost
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.
> 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
Peter Dimov via Boost
> On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:
> > 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.
should library authors be encouraged/required to actually do?
Glen Fernandes via Boost
<bo...@lists.boost.org> wrote:
>
> 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?).
Glen
P F via Boost
> On Jun 18, 2017, at 10:13 AM, Peter Dimov via Boost <bo...@lists.boost.org> wrote:
>
> "P F" wrote:
>
>> 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
> 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.
> What will happen to the already existing system Boost installation?
I believe the install rule copies the files, so they would just be replaced.
> 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.
Vinnie Falco via Boost
<bo...@lists.boost.org> wrote:
> 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.
Boost, including libraries they did not author?
Daniel James 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.
support for it. And I don't think it was a roaring success.
> 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.
Someone needs to volunteer to create the pull requests, and maintain
it in the future.
P F via Boost
> On Jun 18, 2017, at 10:43 AM, Robert Ramey via Boost <bo...@lists.boost.org> wrote:
>
> On 6/18/17 7:30 AM, P F via Boost wrote:
>>> On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost <bo...@lists.boost.org> wrote:
>>>
>>> On 6/17/17 8:55 PM, P F via Boost wrote:
>>>>> 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.
>
> 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)`.
Mateusz Loskot via Boost
> On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:
>>
>> 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 ?
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 ?
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
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
> 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.
Louis Dionne via Boost
> boost@.boost
> > wrote:
>> 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?
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
Robert Ramey 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.
>
> 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)`.
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
P F via Boost
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).
Louis Dionne via Boost
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
blessed by CMake experts (e.g. Stephen Kelly and Daniel Pfeifer), I'm on
board.
> 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?
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
P F via Boost
> On Jun 18, 2017, at 4:09 PM, Louis Dionne via Boost <bo...@lists.boost.org> wrote:
>
>> 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
>
> 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.
>
>
>> 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.
Peter Dimov via Boost
> I intentionally left it unspecified how these files would be generated and
> installed.
this I mean library developers, who the library guidelines target - actually
do?
Louis Dionne via Boost
> 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?
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.
P F via Boost
> On Jun 18, 2017, at 4:05 PM, Daniel James via Boost <bo...@lists.boost.org> wrote:
>
> On 18 June 2017 at 20:05, Louis Dionne via Boost <bo...@lists.boost.org> wrote:
>>
>> 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.
Louis Dionne via Boost
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?
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
Louis Dionne via Boost
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.
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
Peter Dimov 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.
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.
P F via Boost
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?
Rene Rivera via Boost
wrote:
>
> 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?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Vinnie Falco via Boost
<bo...@lists.boost.org> wrote:
> 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.
Richard Hodges via Boost
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
On Mon, 19 Jun 2017 at 01:05, Rene Rivera via Boost <bo...@lists.boost.org>
wrote:
> On Sun, Jun 18, 2017 at 4:09 PM, P F via Boost <bo...@lists.boost.org>
Rene Rivera 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].
>
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.
Niall Douglas via Boost
> On Sun, Jun 18, 2017 at 4:03 PM, Edward Diener via Boost
> <bo...@lists.boost.org> wrote:
>>
>> 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?).
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
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Gary Furnish via Boost
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.
Peter Dimov via Boost
> +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?).
Boost::Whatever ). The usage requirements of Boost::Whatever would add the
include directory (and its dependencies would transitively add their include
directories.)
P F via Boost
> On Jun 18, 2017, at 6:05 PM, Rene Rivera <grafi...@gmail.com> wrote:
>
> On Sun, Jun 18, 2017 at 4:09 PM, P F via Boost <bo...@lists.boost.org <mailto:bo...@lists.boost.org>> wrote:
>
> 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?
>
> 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.
Vicente J. Botet Escriba via Boost
> Howdy all,
>
> This is a request for comments on a possible path for migrating Boost's
> build
> 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