Boost CMake update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Boost CMake update

Boost - Dev mailing list
Hi all,

So I have been working at converting more of boost tests to cmake utilizing
the BCM library, here:

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

This is a build of Boost 1.64, with a majority of the tests integrated. There
is still much more work needed to update the tests, as there are some that
still fail. Also, some of the libraries were skipped due to missing headers in
the 1.64 tag. You can check the library yourself by running cmake:

cd build
mkdir build
cmake ..
cmake --build . --target check

This will build all the tests. You can check the tests for one target with:

cmake --build . --target check-boost_core

Which will run the tests for just `boost_core`.

This was all generated using scripts in https://github.com/pfultz2/boost-cmake

I plan to update this to a newer version of boost. If anyone has fixes or
changes they can send a PR or issue on either repos, and I will try to
incorporate them in.

Thanks,
Paul

.

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

Re: Boost CMake update

Boost - Dev mailing list
I just want to say I've been working on testing this and its
wonderful!  I look forward to seeing some of this merged/reviewed!
The autodetection of libs in particular seems to work much better.

On Fri, Sep 29, 2017 at 11:02 AM, paul via Boost <[hidden email]> wrote:

> Hi all,
>
> So I have been working at converting more of boost tests to cmake utilizing
> the BCM library, here:
>
> https://github.com/boost-cmake/boost/tree/1.64
>
> This is a build of Boost 1.64, with a majority of the tests integrated. There
> is still much more work needed to update the tests, as there are some that
> still fail. Also, some of the libraries were skipped due to missing headers in
> the 1.64 tag. You can check the library yourself by running cmake:
>
> cd build
> mkdir build
> cmake ..
> cmake --build . --target check
>
> This will build all the tests. You can check the tests for one target with:
>
> cmake --build . --target check-boost_core
>
> Which will run the tests for just `boost_core`.
>
> This was all generated using scripts in https://github.com/pfultz2/boost-cmake
>
> I plan to update this to a newer version of boost. If anyone has fixes or
> changes they can send a PR or issue on either repos, and I will try to
> incorporate them in.
>
> Thanks,
> Paul
>
> .
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/29/2017 1:02 PM, paul via Boost wrote:

> Hi all,
>
> So I have been working at converting more of boost tests to cmake utilizing
> the BCM library, here:
>
> https://github.com/boost-cmake/boost/tree/1.64
>
> This is a build of Boost 1.64, with a majority of the tests integrated. There
> is still much more work needed to update the tests, as there are some that
> still fail. Also, some of the libraries were skipped due to missing headers in
> the 1.64 tag. You can check the library yourself by running cmake:
>
> cd build
> mkdir build

Shouldn't this be:

mkdir build
cd build

> cmake ..
> cmake --build . --target check
>
> This will build all the tests. You can check the tests for one target with:
>
> cmake --build . --target check-boost_core
>
> Which will run the tests for just `boost_core`.
>
> This was all generated using scripts in https://github.com/pfultz2/boost-cmake
>
> I plan to update this to a newer version of boost. If anyone has fixes or
> changes they can send a PR or issue on either repos, and I will try to
> incorporate them in.
>
> Thanks,
> Paul


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

Re: Boost CMake update

Boost - Dev mailing list
On Fri, Sep 29, 2017 at 4:25 PM, Edward Diener via Boost
<[hidden email]> wrote:

> On 9/29/2017 1:02 PM, paul via Boost wrote:
>>
>> Hi all,
>>
>> So I have been working at converting more of boost tests to cmake
>> utilizing
>> the BCM library, here:
>>
>> https://github.com/boost-cmake/boost/tree/1.64
>>
>> This is a build of Boost 1.64, with a majority of the tests integrated.
>> There
>> is still much more work needed to update the tests, as there are some that
>> still fail. Also, some of the libraries were skipped due to missing
>> headers in
>> the 1.64 tag. You can check the library yourself by running cmake:
>>
>> cd build
>> mkdir build
>
>
> Shouldn't this be:
>
> mkdir build
> cd build
>
Yes

>> cmake ..
>> cmake --build . --target check
>>
>> This will build all the tests. You can check the tests for one target
>> with:
>>
>> cmake --build . --target check-boost_core
>>
>> Which will run the tests for just `boost_core`.
>>
>> This was all generated using scripts in
>> https://github.com/pfultz2/boost-cmake
>>
>> I plan to update this to a newer version of boost. If anyone has fixes or
>> changes they can send a PR or issue on either repos, and I will try to
>> incorporate them in.
>>
>> Thanks,
>> Paul
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/29/17 10:02 AM, paul via Boost wrote:

> Hi all,
>
> So I have been working at converting more of boost tests to cmake utilizing
> the BCM library, here:
>
> https://github.com/boost-cmake/boost/tree/1.64
>
> This is a build of Boost 1.64, with a majority of the tests integrated. There
> is still much more work needed to update the tests, as there are some that
> still fail. Also, some of the libraries were skipped due to missing headers in
> the 1.64 tag. You can check the library yourself by running cmake:
>
> cd build
> mkdir build
> cmake ..
> cmake --build . --target check
>
> This will build all the tests. You can check the tests for one target with:

Looking at the serialization library test because I'm familiar with it I
see things like:

serialization_archive_test(test_forward_list A)

while in the CMakeLists.txt file I see

[ test-bsl-run_files test_forward_list_ptrs : A  : :  [ requires
cxx11_hdr_forward_list ] ] # BOOST_NO_CXX11_HDR_FORWARD_LIST

In otherwords, the CMake version will run tests which cannot pass.

>
> cmake --build . --target check-boost_core
>
> Which will run the tests for just `boost_core`.
>
> This was all generated using scripts in https://github.com/pfultz2/boost-cmake

Where is the document which describes how to uses these scripts?

>
> I plan to update this to a newer version of boost. If anyone has fixes or
> changes they can send a PR or issue on either repos, and I will try to
> incorporate them in.

I think it's a waste of time trying to apply this to all of boost until
one has demonstrated that the system actually works on test cases.  That
is what we're really going to review here is a library of CMake macros
and these need to testable/demonstrably correct independent of any
particular libraries.

To put it another way:

a) Develop and test the system

If that passes and is accepted

b) Apply to all the libraries desired.

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


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

Re: Boost CMake update

Boost - Dev mailing list
On 9/29/17 9:33 PM, Robert Ramey via Boost wrote:
> On 9/29/17 10:02 AM, paul via Boost wrote:
>> Hi all,
>>
>> So I have been working at converting more of boost tests to cmake
>> utilizing
>> the BCM library, here:
>>
>> https://github.com/boost-cmake/boost/tree/1.64
>>

I'm also not seeing

a) how one just builds the library without running the tests?

b) how one builds dynamic/shared library versions

c) how one includes all that is required by an IDE.

To see how this last can be done, you can look at my CMakeLists.txt in
the serialization library.

Robert Ramey



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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

> On 9/29/17 10:02 AM, paul via Boost wrote:
> >
> > Hi all,
> >
> > So I have been working at converting more of boost tests to cmake
> > utilizing
> > the BCM library, here:
> >
> > https://github.com/boost-cmake/boost/tree/1.64
> >
> > This is a build of Boost 1.64, with a majority of the tests integrated.
> > There
> > is still much more work needed to update the tests, as there are some that
> > still fail. Also, some of the libraries were skipped due to missing
> > headers in
> > the 1.64 tag. You can check the library yourself by running cmake:
> >
> > cd build
> > mkdir build
> > cmake ..
> > cmake --build . --target check
> >
> > This will build all the tests. You can check the tests for one target
> > with:
> Looking at the serialization library test because I'm familiar with it I 
> see things like:
>
> serialization_archive_test(test_forward_list A)
>
> while in the CMakeLists.txt file I see
>
> [ test-bsl-run_files test_forward_list_ptrs : A  : :  [ requires 
> cxx11_hdr_forward_list ] ] # BOOST_NO_CXX11_HDR_FORWARD_LIST
>
> In otherwords, the CMake version will run tests which cannot pass.

Currently, the feature checking from Boost.Config has not been implemented
yet, although this could be fix with a simple `check_include_file`. 


Of course, this is just an initial implementation of the tests in cmake. There
are many areas that need updates from authors, especially since they
understand the test cases better than me. So, any PRs(or feedback) are
welcomed to help improve the tests.

>
> >
> >
> > cmake --build . --target check-boost_core
> >
> > Which will run the tests for just `boost_core`.
> >
> > This was all generated using scripts in https://github.com/pfultz2/boost-c
> > make
> Where is the document which describes how to uses these scripts?

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

>
> >
> >
> > I plan to update this to a newer version of boost. If anyone has fixes or
> > changes they can send a PR or issue on either repos, and I will try to
> > incorporate them in.
> I think it's a waste of time trying to apply this to all of boost until 
> one has demonstrated that the system actually works on test cases.  That 
> is what we're really going to review here is a library of CMake macros 
> and these need to testable/demonstrably correct independent of any 
> particular libraries.

Well we need to know that the cmake modules are sufficient. There are tests
for BCM itself, but this says nothing about how well it will work with boost
libraries. 

Also, doing this in parallel can help move boost quicker to cmake.

>
> To put it another way:
>
> a) Develop and test the system

Thats what is being done.

>
> If that passes and is accepted
>
> b) Apply to all the libraries desired.

No, apply to all libraries period, as authors of upstream libraries shouldn't
hold back a library from moving to cmake.



.

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

Re: Boost CMake update

Boost - Dev mailing list
On 10/2/17 8:27 AM, paul via Boost wrote:
> On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

> Thats what is being done.
>
>>
>> If that passes and is accepted
>>
>> b) Apply to all the libraries desired.
>
> No, apply to all libraries period, as authors of upstream libraries shouldn't
> hold back a library from moving to cmake.

I think it would be unwise to presume that you can enforce this. Such
approaches have failed in the past. You would be better served by
focusing on creating a system whose benefits are sufficiently compelling
that the question of imposing the new system doesn't arise.  To me this
is the main benefit of having such tooling ideas go through the boost
review process.

Robert Ramey

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 2017-09-29 at 21:40 -0700, Robert Ramey via Boost wrote:

> On 9/29/17 9:33 PM, Robert Ramey via Boost wrote:
> >
> > On 9/29/17 10:02 AM, paul via Boost wrote:
> > >
> > > Hi all,
> > >
> > > So I have been working at converting more of boost tests to cmake 
> > > utilizing
> > > the BCM library, here:
> > >
> > > https://github.com/boost-cmake/boost/tree/1.64
> > >
> I'm also not seeing
>
> a) how one just builds the library without running the tests?

Sorry, I kind of assumed cmake knowledge beforehand. To build the library:

cmake --build .

To install:

cmake --build . --target install

Also, you can just build but not run the tests with the `tests` target:

cmake --build . --target tests

And of course, there is a project-specific version of these targets as well:

# Build tests for serialization
cmake --build . --target tests-boost_serialization
# Build and run tests for serialization
cmake --build . --target check-boost_serialization

>
> b) how one builds dynamic/shared library versions

Set `BUILD_SHARED_LIBS` to true, when you run cmake the first time:

cmake -DBUILD_SHARED_LIBS=On ..

>
> c) how one includes all that is required by an IDE.

You set the generator to generate the IDE files:

cmake -G 'CodeBlocks - Unix Makefiles' ..

>
> To see how this last can be done, you can look at my CMakeLists.txt in 
> the serialization library.

I don't follow this at all. I dont see any comments about generating IDE
files.


.

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:

> On 10/2/17 8:27 AM, paul via Boost wrote:
> >
> > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> >
> > Thats what is being done.
> >
> > >
> > >
> > > If that passes and is accepted
> > >
> > > b) Apply to all the libraries desired.
> > No, apply to all libraries period, as authors of upstream libraries
> > shouldn't
> > hold back a library from moving to cmake.
> I think it would be unwise to presume that you can enforce this.

I believe that is what the SC decision was about.

> Such 
> approaches have failed in the past. You would be better served by 
> focusing on creating a system whose benefits are sufficiently compelling 
> that the question of imposing the new system doesn't arise.  

One of the important use cases to support cmake in boost, is to move away from
problematic find modules for `find_package`. 

For example, you may want to support cmake in Boost.Serialization, but
Boost.Iterator does not desire to update to cmake. So now you will need to
create a Findboost_iterator.cmake module for Boost.Serialization. Not only
that, but any downstream users of Boost.Serialization will need to a copy of
the Findboost_iterator.cmake module. Now when the usage requirements for
Boost.Iterator changes all these modules will be wrong.

With the large number of libraries in boost, having boost half-implemented in
cmake will just be a nightmare for users. They will need to figure out which
libraries have cmake support and which ones need find modules. They will need
to fix the modules on their own when the usage requirements for non-cmake
libraries change. 

Also, a lot of the libraries are very intertwined, so its not really possible
to update to cmake piecewise. For example, to implement the build and tests in
cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and
detail, which these libraries already depended on Boost.Config as well.

> To me this 
> is the main benefit of having such tooling ideas go through the boost 
> review process.

The system is already defined by cmake, adn BCM doesn't plan to change that..
The modules are just there to improve the cmake's workflow in the context of
boost.



.

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

Re: Boost CMake update

Boost - Dev mailing list
On 10/2/17 9:59 AM, paul via Boost wrote:

> On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
>> On 10/2/17 8:27 AM, paul via Boost wrote:
>>>
>>> On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
>>>
>>> Thats what is being done.
>>>
>>>>
>>>>
>>>> If that passes and is accepted
>>>>
>>>> b) Apply to all the libraries desired.
>>> No, apply to all libraries period, as authors of upstream libraries
>>> shouldn't
>>> hold back a library from moving to cmake.
>> I think it would be unwise to presume that you can enforce this.
>
> I believe that is what the SC decision was about.

Agreed.  That's why it's flawed.

> One of the important use cases to support cmake in boost, is to move away from
> problematic find modules for `find_package`.

<snip>

Interesting, I look forward to seeing this topic discussed in the review.

> Also, a lot of the libraries are very intertwined, so its not really possible
> to update to cmake piecewise. For example, to implement the build and tests in
> cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and
> detail, which these libraries already depended on Boost.Config as well.

Also very interesting.  Doesn't bode well for a successful
implementation.  But we're anxious to have a look.

>
>> To me this
>> is the main benefit of having such tooling ideas go through the boost
>> review process.
>
> The system is already defined by cmake, adn BCM doesn't plan to change that..
> The modules are just there to improve the cmake's workflow in the context of
> boost.

Hmmmm - so you're saying what?  That there is nothing to be gained by
the boost type of review process? That it's just a question telling
developers to "turn on" CMake.  That every aspect of build/test/post
results is baked into CMake and there is no ambiguity about how to use
it in this context.  Having spent significant amount of time with CMake
myself, this would be a surprise to me.

If you really think this, we can drop the whole idea of boost style
review and just stay with the current situation.  This is that Boost
Steering committee makes a pronouncement, and developers ignore it.

Robert Ramey

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Oct 2, 2017 at 9:59 AM, paul via Boost <[hidden email]>
wrote:

> On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
> > On 10/2/17 8:27 AM, paul via Boost wrote:
> > >
> > > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> > >
> > > Thats what is being done.
> > >
> > > >
> > > >
> > > > If that passes and is accepted
> > > >
> > > > b) Apply to all the libraries desired.
> > > No, apply to all libraries period, as authors of upstream libraries
> > > shouldn't
> > > hold back a library from moving to cmake.
> > I think it would be unwise to presume that you can enforce this.
>
> I believe that is what the SC decision was about.
>

What I believe Robert's, and others, point on this is that the SC can make
pronouncements as to how things have to be. But library authors are free to
ignore such pronouncements. As it's *their* libraries. Hence unless you
convince them of concrete benefits over what they have now you aren't going
to make a lot of forward progress. Just remember that programmers tend to
be inherently lazy (except for Vinnie).

> Such
> > approaches have failed in the past. You would be better served by
> > focusing on creating a system whose benefits are sufficiently compelling
> > that the question of imposing the new system doesn't arise.
>
> One of the important use cases to support cmake in boost, is to move away
> from
> problematic find modules for `find_package`.
>
> For example, you may want to support cmake in Boost.Serialization, but
> Boost.Iterator does not desire to update to cmake. So now you will need to
> create a Findboost_iterator.cmake module for Boost.Serialization. Not only
> that, but any downstream users of Boost.Serialization will need to a copy
> of
> the Findboost_iterator.cmake module. Now when the usage requirements for
> Boost.Iterator changes all these modules will be wrong.
>

Or you could just use conan, and not force any particular build system on
anyone.

With the large number of libraries in boost, having boost half-implemented
> in
> cmake will just be a nightmare for users. They will need to figure out
> which
> libraries have cmake support and which ones need find modules. They will
> need
> to fix the modules on their own when the usage requirements for non-cmake
> libraries change.
>

Or you could tell users that conan is the public interface to Boost and not
force a particular build system on anyone.

Also, a lot of the libraries are very intertwined, so its not really
> possible
> to update to cmake piecewise. For example, to implement the build and
> tests in
> cmake for Boost.Config, we need cmake support for tr1, core, type_traits,
> and
> detail, which these libraries already depended on Boost.Config as well.
>

The suggestion has been made before that it's perfectly possible to provide
a build system agnostic interface to testing and other aspects of building
libraries.


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

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 2017-10-02 at 10:16 -0700, Robert Ramey via Boost wrote:

> On 10/2/17 9:59 AM, paul via Boost wrote:
> >
> > On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
> > >
> > > On 10/2/17 8:27 AM, paul via Boost wrote:
> > > >
> > > >
> > > > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> > > >
> > > > Thats what is being done.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > If that passes and is accepted
> > > > >
> > > > > b) Apply to all the libraries desired.
> > > > No, apply to all libraries period, as authors of upstream libraries
> > > > shouldn't
> > > > hold back a library from moving to cmake.
> > > I think it would be unwise to presume that you can enforce this.
> > I believe that is what the SC decision was about.
> Agreed.  That's why it's flawed.
>
> >
> > One of the important use cases to support cmake in boost, is to move away
> > from
> > problematic find modules for `find_package`.
> <snip>
>
> Interesting, I look forward to seeing this topic discussed in the review.
>
> >
> > Also, a lot of the libraries are very intertwined, so its not really
> > possible
> > to update to cmake piecewise. For example, to implement the build and
> > tests in
> > cmake for Boost.Config, we need cmake support for tr1, core, type_traits,
> > and
> > detail, which these libraries already depended on Boost.Config as well.
> Also very interesting.  Doesn't bode well for a successful 
> implementation.  But we're anxious to have a look.

This email update was the start of successful implementation, so I disagree..

>
> >
> >
> > >
> > > To me this
> > > is the main benefit of having such tooling ideas go through the boost
> > > review process.
> > The system is already defined by cmake, adn BCM doesn't plan to change
> > that..
> > The modules are just there to improve the cmake's workflow in the context
> > of
> > boost.
> Hmmmm - so you're saying what?  That there is nothing to be gained by 
> the boost type of review process?

I am not saying there shouldn't be reviewed, because we want to make sure it
is sufficient for developers and users.

> That it's just a question telling 
> developers to "turn on" CMake.  That every aspect of build/test/post 
> results is baked into CMake and there is no ambiguity about how to use 
> it in this context.  Having spent significant amount of time with CMake 
> myself, this would be a surprise to me.

There is a effective workflow with cmake that can help cover many different
use-cases as outlined by Daniel Pfeifer's Effective CMake talk, and I don't
think we should stray from that.

>
> If you really think this, we can drop the whole idea of boost style 
> review and just stay with the current situation.  This is that Boost 
> Steering committee makes a pronouncement, and developers ignore it.

I dont think this.



.

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 2017-10-02 at 10:33 -0700, Rene Rivera wrote:

> On Mon, Oct 2, 2017 at 9:59 AM, paul via Boost <[hidden email]>
> wrote:
> > On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
> > > On 10/2/17 8:27 AM, paul via Boost wrote:
> > > >
> > > > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> > > >
> > > > Thats what is being done.
> > > >
> > > > >
> > > > >
> > > > > If that passes and is accepted
> > > > >
> > > > > b) Apply to all the libraries desired.
> > > > No, apply to all libraries period, as authors of upstream libraries
> > > > shouldn't
> > > > hold back a library from moving to cmake.
> > > I think it would be unwise to presume that you can enforce this.
> >
> > I believe that is what the SC decision was about.
> What I believe Robert's, and others, point on this is that the SC can make
> pronouncements as to how things have to be. But library authors are free to
> ignore such pronouncements. As it's *their* libraries. Hence unless you
> convince them of concrete benefits over what they have now you aren't going
> to make a lot of forward progress. Just remember that programmers tend to be
> inherently lazy (except for Vinnie).

Yes, which is why I am generating an initial implementation of cmake, instead
of relying on each individual author.

>
> > > Such 
> > > approaches have failed in the past. You would be better served by 
> > > focusing on creating a system whose benefits are sufficiently
> > compelling 
> > > that the question of imposing the new system doesn't arise.  
> >
> > One of the important use cases to support cmake in boost, is to move away
> > from
> > problematic find modules for `find_package`. 
> >
> > For example, you may want to support cmake in Boost.Serialization, but
> > Boost.Iterator does not desire to update to cmake. So now you will need to
> > create a Findboost_iterator.cmake module for Boost.Serialization. Not only
> > that, but any downstream users of Boost.Serialization will need to a copy
> > of
> > the Findboost_iterator.cmake module. Now when the usage requirements for
> > Boost.Iterator changes all these modules will be wrong.
> Or you could just use conan, and not force any particular build system on
> anyone.

Or rather you are replacing a build system with another. Or in the case of
cmake, replacing a a meta-build system with a meta-meta build system(that also
happens to be a package manager). 

It doesn't integrate well with cmake. You can't do `add_subdirectory` with
packages that conan provides. 

Also, if you are in the 'install' camp, conan doesn't properly tell cmake
where the dependencies are. This is why you have to add special conan cmake
functions to your cmake like `conan_basic_setup`, which still has problems.

If you use any of cmake's find_* command, it will no longer work because even
with `conan_basic_setup`, cmake still doesn't know where your dependencies
are.

Furthermore, adding `conan_basic_setup` to your cmake, you are no longer
supporting cmake users. You could add an additional `if` or put the conan
logic in a python file to support cmake users and conan, but now you are
supporting two build systems.

>
> > With the large number of libraries in boost, having boost half-implemented
> > in
> > cmake will just be a nightmare for users. They will need to figure out
> > which
> > libraries have cmake support and which ones need find modules. They will
> > need
> > to fix the modules on their own when the usage requirements for non-cmake
> > libraries change. 
> Or you could tell users that conan is the public interface to Boost and not
> force a particular build system on anyone. 
>
> > Also, a lot of the libraries are very intertwined, so its not really
> > possible
> > to update to cmake piecewise. For example, to implement the build and
> > tests in
> > cmake for Boost.Config, we need cmake support for tr1, core, type_traits,
> > and
> > detail, which these libraries already depended on Boost.Config as well.
> The suggestion has been made before that it's perfectly possible to provide
> a build system agnostic interface to testing and other aspects of building
> libraries. 

It is, but the closest implementation I have seen of this is cmake.


.

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
paul wrote:

> Hi all,
>
> So I have been working at converting more of boost tests to cmake
> utilizing the BCM library, here:
>
> https://github.com/boost-cmake/boost/tree/1.64

This looks pretty good.

A few comments:

    include(bcm/share/bcm/cmake/BCMConfig.cmake)

bcm/share/bcm doesn't seem the right place. tools/bcm, more likely.

Looking at
https://github.com/boost-cmake/boost/blob/1.64/libs/core/CMakeLists.txt as
an example, clean and tidy; but I'd like to know what is the suggested way
of keeping this file up to date. At minimum, this line:

    bcm_setup_version(VERSION 1.64.0)

needs to be updated per each release; how is this to be done?

I had the version in a separate version.cmake file for this reason; so that
version.cmake could be mass-updated by a script after each release, without
having to either regenerate all CMakeLists files - implying that all local
changes would be lost - or requiring maintainers to keep the version up to
date - which they will not.

A similar question arises with the sources and the dependencies, although
those do not change as often or on such a fixed schedule. (I had those in
separate files as well, for similar reasons, although one could go either
way here.)

    find_package(boost_assert)

As I already mentioned a number of times, this in my opinion must be

    find_package(boost_assert VERSION 1.64.0 EXACT)

because there is never, ever, a scenario in which I want boost_core 1.64.0
to link to boost_assert 1.58.0. (Also, REQUIRED, as otherwise errors are not
as informative.)

    target_link_libraries(boost_core INTERFACE boost::assert)

This manual specification of dependencies duplicates the find_package. These
two could potentially be folded into something like

    bcm_dependency(assert INTERFACE)

Moving on to
https://github.com/boost-cmake/boost/blob/1.64/libs/core/test/CMakeLists.txt,

    bcm_test(NAME core_addressof_test SOURCES addressof_test.cpp)

In the Jamfile, this is

    run addressof_test.cpp ;

which automatically generates a name for the test. It would probably be more
convenient if bcm_test could do that itself as well, including adding a
prefix, so that

    bcm_test(SOURCES addressof_test.cpp)

declared core_addressof_test, and

    bcm_test(SOURCES addressof_test.cpp NAME addressof_test_name)

declared core_addressof_test_name so that one did not have to remember to
prefix everything with core_.

Apart from that, nice work, CMake fans ought to be happy. Needs to be
brought up to date with master though. :-)


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

Re: Boost CMake update

Boost - Dev mailing list
On Tue, 2017-10-03 at 19:58 +0300, Peter Dimov via Boost wrote:

> paul wrote:
>
> >
> > Hi all,
> >
> > So I have been working at converting more of boost tests to cmake 
> > utilizing the BCM library, here:
> >
> > https://github.com/boost-cmake/boost/tree/1.64
> This looks pretty good.

Thanks.

>
> A few comments:
>
>     include(bcm/share/bcm/cmake/BCMConfig.cmake)
>
> bcm/share/bcm doesn't seem the right place. tools/bcm, more likely.

Yea, I will look into moving that.

>
> Looking at 
> https://github.com/boost-cmake/boost/blob/1.64/libs/core/CMakeLists.txt as 
> an example, clean and tidy; but I'd like to know what is the suggested way 
> of keeping this file up to date. At minimum, this line:
>
>     bcm_setup_version(VERSION 1.64.0)
>
> needs to be updated per each release; how is this to be done?
>
> I had the version in a separate version.cmake file for this reason; so that 
> version.cmake could be mass-updated by a script after each release, without 
> having to either regenerate all CMakeLists files - implying that all local 
> changes would be lost - or requiring maintainers to keep the version up to 
> date - which they will not.

Yea I can set it up to read the version from a file.

>
> A similar question arises with the sources and the dependencies, although 
> those do not change as often or on such a fixed schedule. (I had those in 
> separate files as well, for similar reasons, although one could go either 
> way here.)
>
>     find_package(boost_assert)
>
> As I already mentioned a number of times, this in my opinion must be
>
>     find_package(boost_assert VERSION 1.64.0 EXACT)
>
> because there is never, ever, a scenario in which I want boost_core 1.64.0 
> to link to boost_assert 1.58.0.

The user may want to use boost_core 1.64.0 with boost_assert 1.64.1 or 1.65
because perhaps the newer version is from develop that fixes a problem they
are having.


> (Also, REQUIRED, as otherwise errors are not 
> as informative.)

True, although some dependencies are optional, which I dont really account for
yet.

>
>     target_link_libraries(boost_core INTERFACE boost::assert)
>
> This manual specification of dependencies duplicates the find_package.
> These 
> two could potentially be folded into something like
>
>     bcm_dependency(assert INTERFACE)

So this would be something like:

function(bcm_dependency name type)
    find_package(boost_${name})
    target_link_libraries(${PROJECT_NAME} ${type} ${name})
endfunction()

I am not sure how well that works if the user wants to make the dependency
optional or required, but I think it could be made to work. I have considered
adding a function like:

bcm_boost_depends(boost_core assert config)

In general, I was trying to avoid abstracting out too much cmake, as it makes
it unfamiliar to cmake users. Plus, I would like utilities that can be
eventually merged to cmake upstream. However, if there are a lot of developers
who would really like to write as a above, I could definitely add it.

>
> Moving on to 
> https://github.com/boost-cmake/boost/blob/1.64/libs/core/test/CMakeLists.txt
> ,
>
>     bcm_test(NAME core_addressof_test SOURCES addressof_test.cpp)
>
> In the Jamfile, this is
>
>     run addressof_test.cpp ;
>
> which automatically generates a name for the test. It would probably be
> more 
> convenient if bcm_test could do that itself as well, including adding a 
> prefix, so that
>
>     bcm_test(SOURCES addressof_test.cpp)
>
> declared core_addressof_test, and
>
>     bcm_test(SOURCES addressof_test.cpp NAME addressof_test_name)
>
> declared core_addressof_test_name so that one did not have to remember to 
> prefix everything with core_.

That is something I am seriously considering. Although, if you want to change
the properties, a name would be needed, so for something like:

bcm_test(NAME core_typeinfo_test_no_rtti SOURCES typeinfo_test.cpp)
set_target_properties(core_typeinfo_test_no_rtti PROPERTIES CXX_RTTI Off)

The name would probably need to stay. I am also considering having `bcm_test`
enforce that names start with the project name, so it better avoids name
conflicts.

>
> Apart from that, nice work, CMake fans ought to be happy. Needs to be 
> brought up to date with master though. :-)
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
> st

.

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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/29/2017 1:02 PM, paul via Boost wrote:

> Hi all,
>
> So I have been working at converting more of boost tests to cmake utilizing
> the BCM library, here:
>
> https://github.com/boost-cmake/boost/tree/1.64
>
> This is a build of Boost 1.64, with a majority of the tests integrated. There
> is still much more work needed to update the tests, as there are some that
> still fail. Also, some of the libraries were skipped due to missing headers in
> the 1.64 tag. You can check the library yourself by running cmake:
>
> cd build
> mkdir build
> cmake ..
> cmake --build . --target check
>
> This will build all the tests. You can check the tests for one target with:
>
> cmake --build . --target check-boost_core
>
> Which will run the tests for just `boost_core`.
>
> This was all generated using scripts in https://github.com/pfultz2/boost-cmake
>
> I plan to update this to a newer version of boost. If anyone has fixes or
> changes they can send a PR or issue on either repos, and I will try to
> incorporate them in.

Were the CMakeLists.txt files, using your BCM library, for individual
library tests generated manually or did you use some sort of script or
program to generate them ?

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



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

Re: Boost CMake update

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
paul wrote:

> > As I already mentioned a number of times, this in my opinion must be
> >
> >     find_package(boost_assert VERSION 1.64.0 EXACT)
> >
> > because there is never, ever, a scenario in which I want boost_core
> > 1.64.0 to link to boost_assert 1.58.0.
>
> The user may want to use boost_core 1.64.0 with boost_assert 1.64.1 or
> 1.65 because perhaps the newer version is from develop that fixes a
> problem they are having.

Yeah. How would this scenario come into being though? Suppose you have
1.64.0 already installed; you replace boost_assert from develop and now, as
also mentioned a number of times, you have all manners of ODR violations
because your libraries are built against boost_assert 1.64.0 and you're
including the develop one.


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

Re: Boost CMake update

Boost - Dev mailing list
On Wed, 2017-10-04 at 03:09 +0300, Peter Dimov via Boost wrote:

> paul wrote:
> >
> > >
> > > As I already mentioned a number of times, this in my opinion must be
> > >
> > >     find_package(boost_assert VERSION 1.64.0 EXACT)
> > >
> > > because there is never, ever, a scenario in which I want boost_core 
> > > 1.64.0 to link to boost_assert 1.58.0.
> > The user may want to use boost_core 1.64.0 with boost_assert 1.64.1 or 
> > 1.65 because perhaps the newer version is from develop that fixes a 
> > problem they are having.
> Yeah. How would this scenario come into being though? Suppose you have 
> 1.64.0 already installed; you replace boost_assert from develop and now, as 
> also mentioned a number of times, you have all manners of ODR violations 
> because your libraries are built against boost_assert 1.64.0 and you're 
> including the develop one. 

If you change your dependencies, you would most likely change the library that
depend on those as well. 

Even if they didn't rebuild, it doesn't always mean it would lead to an ODR
violation, as the change could only affect some assert macros that are not
used in the definition.

Of course, adding the version doesn't prevent the scenario you mention. They
could just reinstall a whole new version of boost 1.65 and the libraries that
were built against boost 1.64 would be broken.

Or they could create a superproject of the different boost modules, with using
1.64 for everything except boost_assert. This still would affect downstream
libraries that were built against an older version of boost.

Paul


.

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

Re: Boost CMake update

Boost - Dev mailing list
paul wrote:

> Of course, adding the version doesn't prevent the scenario you mention.
> They could just reinstall a whole new version of boost 1.65 and the
> libraries that were built against boost 1.64 would be broken.

I'm talking about Boost libraries here, not theirs. Boost library X 1.64.0
is built against Boost library Y 1.64.0. You update Y to 1.65.0, X is now
broken.

> If you change your dependencies, you would most likely change the library
> that depend on those as well.

You should, but if you don't, nobody will tell you. That's the point of
requesting a specific dependency version - if you forget to update the other
libraries, you get an error.

> Even if they didn't rebuild, it doesn't always mean it would lead to an
> ODR violation, as the change could only affect some assert macros that are
> not used in the definition.

Yeah, sure, it's often asymptomatic. That's half of the fun. And of course
boost_assert here is an example. I'm not talking about boost_assert
specifically.


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