Boost CMake support - Request for Comment

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Boost CMake support - Request for Comment

Boost - Dev mailing list
Background
==========

My personal knowledge of build systems is somewhat limited.

a) I don't really understand CMake all that well.  I have made
CMakeLists.txt files for both the serialization library and the safe
numerics libraries as an aid to build and maintain IDE and make files
used in running tests and posting results to CDash.

b) I don't really understand our current system, Boost Build, very well
either.  I've made jam files for building and running tests for the
serialization and safe numerics libraries.

c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
from C++Now 2017  “Effective CMake" -
https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.

Despite my lack of knowledge in this area, or perhaps because of it,
I've volunteered to direct the effort to evolve Boost so that users of
Boost can avail themselves of the benefits of CMake.  This effort will
be organized as follows:

a) A discussion on the boost developers mailing list with the goal of
reaching a consensus as to what benefits CMake can and should provide to
users and developers of Boost.  This effort will commence with the
posting of this notice.  I hope that this discussion can be more or less
resolved within 30 days.

b) I will then synthesize from the above discussion a call for proposals
which lists the requirements and requirements.

c) Those proposing CMake for boost will have approximately 90 days to
prepare their proposals.  Their proposal are expected to look similar to
a boost library proposal.  That is they are expected to have some
(CMake) code, along with tests, documentation including tutorials and
reference.  This is only an expectation.  It's conceivable that such a
proposal might only contain conventions and and samples of what boost
library should contain to fulfill the requirements. As with boost
libraries, submissions are not required to totally complete.  But they
have to be sufficiently complete to convince reviewers the the
submission fulfills the stated requirements and can be finished in good
time.

d) After the 90 day period, submissions will be reviewed simultaneously.
  Note that this is at a variance from normal boost procedure of
reviewing submissions one at a time.  Since we expect to receive a
number of submissions and only one can be accepted, the normal boost
protocol can't really function.  Target date for this review is 1
February 2019.

e) After the review period the review manager will prepare a report
which includes the decision of which submission will be accepted into
the official boost distribution.  Currently, I, Robert Ramey, expect to
be review manager.  However, it's possible that this by the time the
review is undertaken, this coveted position could be assigned to some
more worthy candidate.

Scope, Requirements and Features
================================

We presume that submissions will fulfill the applicable requirements of
any boost submission.  In addition we would like to see the following
addressed.

Library Build
-------------
    “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk 
Recommends that all libraries - including header only libraries have a
CMakeList.txt file.  What should this include for Boost Libraries?
               

Library Test
------------
        Should facilities for "testing" be only done by developers? or should
users who acquire library packages also be able to test libraries.
        Should CMake testing results posting be used - CDASH?
        Should we just skip the issue of Library Testing and continue to depend
on Boost Build.

Library Packaging
-----------------
        Is the library packaging facility provide by CMake - CPACK - useful to
boost.  Should boost libraries be updated to support it?

Dependencies
------------
        If the above is implemented, can we depend upon CMake to handle library
dependencies?  Or does some special functionality
        Do circular dependencies constitute a problem?

Modularity
----------
        Currently boost is organized as a tightly integrated group of
libraries.  This organization manifests itself in a number of ways.
                We have a Boost "super project" in github.  Boost libraries are "sub
projects" of this super project.  This known structure is exploited by
and depended upon by boost tools.  Should CMake support continue this
policy/design.
                We distribute boost as "super project".  Should we continue to do this
or distribute libraries on a library by library basis.  Does CMake/CPACK
etc. make this "simple"?

Documentation/testing
---------------------
        What support should be require for uses of Boost CMake implementation.
Documentation, examples, templates for helping library developers.  How
should the CMake design/implementation be tested?

Other considerations
--------------------
add your requirement/features here.
               

Useful Resources
===============
        “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
        https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
        https://github.com/purpleKarrot/Boost.CMake
        https://www.youtube.com/watch?v=eC9-iRN2b04

Please try to keep this discussion on this list.

I know that there has been a lot going on on slack. But having it in two
places makes it harder for me to review and summarize.  Also slack
doesn't conveniently maintain comment hierarchy.  So please try to keep
this discussion on this list.

Robert Ramey




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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:

> Background
> ==========
>
> My personal knowledge of build systems is somewhat limited.
>
> a) I don't really understand CMake all that well.  I have made
> CMakeLists.txt files for both the serialization library and the safe
> numerics libraries as an aid to build and maintain IDE and make files
> used in running tests and posting results to CDash.
>
> b) I don't really understand our current system, Boost Build, very well
> either.  I've made jam files for building and running tests for the
> serialization and safe numerics libraries.
>
> c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
> from C++Now 2017  “Effective CMake" -
> https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
>
> Despite my lack of knowledge in this area, or perhaps because of it,
> I've volunteered to direct the effort to evolve Boost so that users of
> Boost can avail themselves of the benefits of CMake.  This effort will
> be organized as follows:
>
> a) A discussion on the boost developers mailing list with the goal of
> reaching a consensus as to what benefits CMake can and should provide to
> users and developers of Boost.  This effort will commence with the
> posting of this notice.  I hope that this discussion can be more or less
> resolved within 30 days.
>
> b) I will then synthesize from the above discussion a call for proposals
> which lists the requirements and requirements.
>
> c) Those proposing CMake for boost will have approximately 90 days to
> prepare their proposals.  Their proposal are expected to look similar to
> a boost library proposal.  That is they are expected to have some
> (CMake) code, along with tests, documentation including tutorials and
> reference.  This is only an expectation.  It's conceivable that such a
> proposal might only contain conventions and and samples of what boost
> library should contain to fulfill the requirements. As with boost
> libraries, submissions are not required to totally complete.  But they
> have to be sufficiently complete to convince reviewers the the
> submission fulfills the stated requirements and can be finished in good
> time.
>
> d) After the 90 day period, submissions will be reviewed simultaneously.
>   Note that this is at a variance from normal boost procedure of
> reviewing submissions one at a time.  Since we expect to receive a
> number of submissions and only one can be accepted, the normal boost
> protocol can't really function.  Target date for this review is 1
> February 2019.
>
> e) After the review period the review manager will prepare a report
> which includes the decision of which submission will be accepted into
> the official boost distribution.  Currently, I, Robert Ramey, expect to
> be review manager.  However, it's possible that this by the time the
> review is undertaken, this coveted position could be assigned to some
> more worthy candidate.
>
> Scope, Requirements and Features
> ================================
>
> We presume that submissions will fulfill the applicable requirements of
> any boost submission.  In addition we would like to see the following
> addressed.
>
> Library Build
> -------------
>        “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk 
> Recommends that all libraries - including header only libraries have a
> CMakeList.txt file.  What should this include for Boost Libraries?
>
>
> Library Test
> ------------
>      Should facilities for "testing" be only done by developers? or
> should users who acquire library packages also be able to test libraries.
>      Should CMake testing results posting be used - CDASH?
>      Should we just skip the issue of Library Testing and continue to
> depend on Boost Build.
>
> Library Packaging
> -----------------
>      Is the library packaging facility provide by CMake - CPACK - useful
> to boost.  Should boost libraries be updated to support it?
>
> Dependencies
> ------------
>      If the above is implemented, can we depend upon CMake to handle
> library dependencies?  Or does some special functionality
>      Do circular dependencies constitute a problem?
>
> Modularity
> ----------
>      Currently boost is organized as a tightly integrated group of
> libraries.  This organization manifests itself in a number of ways.
>          We have a Boost "super project" in github.  Boost libraries are
> "sub projects" of this super project.  This known structure is exploited
> by and depended upon by boost tools.  Should CMake support continue this
> policy/design.
>          We distribute boost as "super project".  Should we continue to
> do this or distribute libraries on a library by library basis.  Does
> CMake/CPACK etc. make this "simple"?
>
> Documentation/testing
> ---------------------
>      What support should be require for uses of Boost CMake
> implementation. Documentation, examples, templates for helping library
> developers.  How should the CMake design/implementation be tested?
>
> Other considerations
> --------------------
> add your requirement/features here.
>
>
> Useful Resources
> ===============
>      “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
>      https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
>      https://github.com/purpleKarrot/Boost.CMake
>      https://www.youtube.com/watch?v=eC9-iRN2b04
>
> Please try to keep this discussion on this list.
>
> I know that there has been a lot going on on slack. But having it in two
> places makes it harder for me to review and summarize.  Also slack
> doesn't conveniently maintain comment hierarchy.  So please try to keep
> this discussion on this list.

I strongly suggest that the goal of using CMake with Boost begin with
making Boost libraries, whether header-only or built, available to CMake
projects. This also means that we have a way of testing whether or not
such a solution actually works for any given Boost library. My own
preference for testing whether or not such a solution would work or not
would be to use our current b2/Boost Build test jamfiles, but if this is
too difficult to do we still need some way to test the solution for each
library so each library maintainer can see whether or not the solution
we choose works for his library.

This should be our first goal and all other goals should be tabled until
and when we can have a solution where this works flawlessly and there is
a general agreement that whatever proposal is chosen to implement this
is best.

Only when the above is fully accomplished should Boost then look into
the goal of using CMake internally, perhaps for test, docs, building
libraries, or what-not. We need to work this way because every solution
is bound to end with comments that it does X but does not do Y or it
does X and Y but does not do Z, and we all know where these endless
arguments end: that we end up doing nothing because we start by trying
to do too much and we can never reach agreement.

>
> Robert Ramey


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list

> I strongly suggest that the goal of using CMake with Boost begin with
> making Boost libraries, whether header-only or built, available to
> CMake projects. This also means that we have a way of testing whether
> or not such a solution actually works for any given Boost library. My
> own preference for testing whether or not such a solution would work
> or not would be to use our current b2/Boost Build test jamfiles, but
> if this is too difficult to do we still need some way to test the
> solution for each library so each library maintainer can see whether
> or not the solution we choose works for his library.

Are you talking about writing a CMake Config for installed boost?
If so I'm strongly in favor of doing so! You'd need some
BoostConfig.cmake files with appropriate contents. They are similar to
pkgconfig files, so small text files. Those can be (mostly) generated by
CMake when it is used to build boost and in the end they replace the
FindBoost.cmake currently shipped with CMake (and which the CMake
maintainers dislike)

Starting from the "other side" would allow some experimentation on how
Boost can be consumed by CMake projects and will show many pitfalls
early. For example one would need to think about how to deal with the
variants (static/dynamic, debug/release[actually simple], static/dynamic
runtime, versions installed to same folder, ...)

If this is solved, one can go further and implement the actual build
system. Note that at this point naming conventions are already
established and the current build system can be used to generate these
files requiring less effort.



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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via
> Boost
> Sent: Monday, October 1, 2018 7:07 PM
>
> [...]
>
> a) A discussion on the boost developers mailing list with the goal of
> reaching a consensus as to what benefits CMake can and should provide to
> users and developers of Boost.  This effort will commence with the
> posting of this notice.  I hope that this discussion can be more or less
> resolved within 30 days.

Personally, I hope to gain two things by this effort:

1) I would like to be able to clone the boost super project and/or
individual boost libraries into a subfolder of my cmake based app and use
those libraries along the lines of
  - add_subdirectory( libs/boost ) // assuming the super projects resides in \
                                     (<app_root>/libs/boost)
  - target_link_libraries( my_app
        PRIVATE
            Boost::static_assert
            Boost::filesystem
            Boost::circular_buffer )

  Which should make sure that
  a) All used boost libraries are built with the compiler flags specified
     in my cmake toolchain file, or the top level CMakeLists.txt file from
     my app project.
    (In particular c++ version and anything that influences ABI/API)  
  b) Headers are found at their original location without any need to copy
     them to some installation/staging directory
  c) (Which is probably the same as b)) My IDE (that understands CMake files)
     should be able to find and parse the source and header files (e.g. for
     "go to definition" operations)

2) It should be possible to compile and install a boost release via the customary
   - cmake <path to boost_root> \
        -DCMAKE_INSTALL_PREFIX=<path> \
        -DCMAKE_TOOLCHAIN_FILE=<path> \
        [other options]
   - cmake --build .
   - cmake --build . --target install
   Again respecting all compilation flags specified in the toolchain file and
   installing a) headers, b) compiled libraries c) the respective library
   cmake config files. The goal is to provide a cmake based installation
   procedure that can be easily used by package managers like conan, vcpkg,
   apt, cget and so on.

In addition to those points, it would probably be prudent to also allow tests
(for a individual library as well as the whole boost release) to be run via
cmake / ctest and cdash, but this is less important for me as a user and I
have no opinions on the details of that.
   
Best

Mike


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

Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Edward Diener via Boost
> Sent: Monday, October 1, 2018 8:00 PM
>
> On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:
> > Background
> > ==========
> >
> > My personal knowledge of build systems is somewhat limited.
> >
> > a) I don't really understand CMake all that well.  I have made
> > CMakeLists.txt files for both the serialization library and the safe
> > numerics libraries as an aid to build and maintain IDE and make files
> > used in running tests and posting results to CDash.
> >
> > b) I don't really understand our current system, Boost Build, very well
> > either.  I've made jam files for building and running tests for the
> > serialization and safe numerics libraries.
> >
> > c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
> > from C++Now 2017  “Effective CMake" -
> > https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
> >
> > Despite my lack of knowledge in this area, or perhaps because of it,
> > I've volunteered to direct the effort to evolve Boost so that users of
> > Boost can avail themselves of the benefits of CMake.  This effort will
> > be organized as follows:
> >
> > a) A discussion on the boost developers mailing list with the goal of
> > reaching a consensus as to what benefits CMake can and should provide to
> > users and developers of Boost.  This effort will commence with the
> > posting of this notice.  I hope that this discussion can be more or less
> > resolved within 30 days.
> >
> > b) I will then synthesize from the above discussion a call for proposals
> > which lists the requirements and requirements.
> >
> > c) Those proposing CMake for boost will have approximately 90 days to
> > prepare their proposals.  Their proposal are expected to look similar to
> > a boost library proposal.  That is they are expected to have some
> > (CMake) code, along with tests, documentation including tutorials and
> > reference.  This is only an expectation.  It's conceivable that such a
> > proposal might only contain conventions and and samples of what boost
> > library should contain to fulfill the requirements. As with boost
> > libraries, submissions are not required to totally complete.  But they
> > have to be sufficiently complete to convince reviewers the the
> > submission fulfills the stated requirements and can be finished in good
> > time.
> >
> > d) After the 90 day period, submissions will be reviewed simultaneously.
> >   Note that this is at a variance from normal boost procedure of
> > reviewing submissions one at a time.  Since we expect to receive a
> > number of submissions and only one can be accepted, the normal boost
> > protocol can't really function.  Target date for this review is 1
> > February 2019.
> >
> > e) After the review period the review manager will prepare a report
> > which includes the decision of which submission will be accepted into
> > the official boost distribution.  Currently, I, Robert Ramey, expect to
> > be review manager.  However, it's possible that this by the time the
> > review is undertaken, this coveted position could be assigned to some
> > more worthy candidate.
> >
> > Scope, Requirements and Features
> > ================================
> >
> > We presume that submissions will fulfill the applicable requirements of
> > any boost submission.  In addition we would like to see the following
> > addressed.
> >
> > Library Build
> > -------------
> >        “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
> > Recommends that all libraries - including header only libraries have a
> > CMakeList.txt file.  What should this include for Boost Libraries?
> >
> >
> > Library Test
> > ------------
> >      Should facilities for "testing" be only done by developers? or
> > should users who acquire library packages also be able to test libraries.
> >      Should CMake testing results posting be used - CDASH?
> >      Should we just skip the issue of Library Testing and continue to
> > depend on Boost Build.
> >
> > Library Packaging
> > -----------------
> >      Is the library packaging facility provide by CMake - CPACK - useful
> > to boost.  Should boost libraries be updated to support it?
> >
> > Dependencies
> > ------------
> >      If the above is implemented, can we depend upon CMake to handle
> > library dependencies?  Or does some special functionality
> >      Do circular dependencies constitute a problem?
> >
> > Modularity
> > ----------
> >      Currently boost is organized as a tightly integrated group of
> > libraries.  This organization manifests itself in a number of ways.
> >          We have a Boost "super project" in github.  Boost libraries are
> > "sub projects" of this super project.  This known structure is exploited
> > by and depended upon by boost tools.  Should CMake support continue this
> > policy/design.
> >          We distribute boost as "super project".  Should we continue to
> > do this or distribute libraries on a library by library basis.  Does
> > CMake/CPACK etc. make this "simple"?
> >
> > Documentation/testing
> > ---------------------
> >      What support should be require for uses of Boost CMake
> > implementation. Documentation, examples, templates for helping library
> > developers.  How should the CMake design/implementation be tested?
> >
> > Other considerations
> > --------------------
> > add your requirement/features here.
> >
> >
> > Useful Resources
> > ===============
> >      “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
> >      https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
> >      https://github.com/purpleKarrot/Boost.CMake
> >      https://www.youtube.com/watch?v=eC9-iRN2b04
> >
> > Please try to keep this discussion on this list.
> >
> > I know that there has been a lot going on on slack. But having it in two
> > places makes it harder for me to review and summarize.  Also slack
> > doesn't conveniently maintain comment hierarchy.  So please try to keep
> > this discussion on this list.
>
> I strongly suggest that the goal of using CMake with Boost begin with
> making Boost libraries, whether header-only or built, available to CMake
> projects. This also means that we have a way of testing whether or not
> such a solution actually works for any given Boost library. My own
> preference for testing whether or not such a solution would work or not
> would be to use our current b2/Boost Build test jamfiles, but if this is
> too difficult to do we still need some way to test the solution for each
> library so each library maintainer can see whether or not the solution
> we choose works for his library.
>
> This should be our first goal and all other goals should be tabled until
> and when we can have a solution where this works flawlessly and there is
> a general agreement that whatever proposal is chosen to implement this
> is best.
>
> Only when the above is fully accomplished should Boost then look into
> the goal of using CMake internally, perhaps for test, docs, building
> libraries, or what-not. We need to work this way because every solution
> is bound to end with comments that it does X but does not do Y or it
> does X and Y but does not do Z, and we all know where these endless
> arguments end: that we end up doing nothing because we start by trying
> to do too much and we can never reach agreement.

I agree with you in so far, that the focus should be on the interface
(how to consume boost libraries) and less on the implementation details,
but I see two practical reasons, why it is beneficial to immediately
use cmake (at least) for building too:

1) Creating a CMake target for a separately compiled binary that can be
   consumed by the user is about the same effort as using cmake to build
   the library (if necessary) in which case you get the interface
   information for free (switching to cmake for unit-tests and docs is a
   different topic).
 
2) "making Boost libraries [...] available to CMake projects" for me also
   means I have an easy way to compile those libraries with specific
   compiler flags that match my project settings - otherwise, what is the
   advantage compared to the current mechanism that is already build into
   cmake?
   Ensuring consistent build flags is relatively easy if all libraries use
   the same build system (in this case cmake) but can become quite complex
   if you want to implement an automatic translation from cmake to b2 or
   vice versa.

So yes, while a library (build-) interface and consummation should be the
focus of the review, I'd expect that at least building the libraries with
cmake will be the simplest way to implement that interface.

Just to be completely clear: Just because the "reference implementation"
of a cmake interface is probably a cmake-based build, that doesn't mean
everyone has to actually adopt that reference implementation as long as
the interface is consistent.

Mike


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On 10/8/2018 6:15 AM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Edward Diener via Boost
>> Sent: Monday, October 1, 2018 8:00 PM
>>
>> On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:
>>> Background
>>> ==========
>>>
>>> My personal knowledge of build systems is somewhat limited.
>>>
>>> a) I don't really understand CMake all that well.  I have made
>>> CMakeLists.txt files for both the serialization library and the safe
>>> numerics libraries as an aid to build and maintain IDE and make files
>>> used in running tests and posting results to CDash.
>>>
>>> b) I don't really understand our current system, Boost Build, very well
>>> either.  I've made jam files for building and running tests for the
>>> serialization and safe numerics libraries.
>>>
>>> c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
>>> from C++Now 2017  “Effective CMake" -
>>> https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
>>>
>>> Despite my lack of knowledge in this area, or perhaps because of it,
>>> I've volunteered to direct the effort to evolve Boost so that users of
>>> Boost can avail themselves of the benefits of CMake.  This effort will
>>> be organized as follows:
>>>
>>> a) A discussion on the boost developers mailing list with the goal of
>>> reaching a consensus as to what benefits CMake can and should provide to
>>> users and developers of Boost.  This effort will commence with the
>>> posting of this notice.  I hope that this discussion can be more or less
>>> resolved within 30 days.
>>>
>>> b) I will then synthesize from the above discussion a call for proposals
>>> which lists the requirements and requirements.
>>>
>>> c) Those proposing CMake for boost will have approximately 90 days to
>>> prepare their proposals.  Their proposal are expected to look similar to
>>> a boost library proposal.  That is they are expected to have some
>>> (CMake) code, along with tests, documentation including tutorials and
>>> reference.  This is only an expectation.  It's conceivable that such a
>>> proposal might only contain conventions and and samples of what boost
>>> library should contain to fulfill the requirements. As with boost
>>> libraries, submissions are not required to totally complete.  But they
>>> have to be sufficiently complete to convince reviewers the the
>>> submission fulfills the stated requirements and can be finished in good
>>> time.
>>>
>>> d) After the 90 day period, submissions will be reviewed simultaneously.
>>>    Note that this is at a variance from normal boost procedure of
>>> reviewing submissions one at a time.  Since we expect to receive a
>>> number of submissions and only one can be accepted, the normal boost
>>> protocol can't really function.  Target date for this review is 1
>>> February 2019.
>>>
>>> e) After the review period the review manager will prepare a report
>>> which includes the decision of which submission will be accepted into
>>> the official boost distribution.  Currently, I, Robert Ramey, expect to
>>> be review manager.  However, it's possible that this by the time the
>>> review is undertaken, this coveted position could be assigned to some
>>> more worthy candidate.
>>>
>>> Scope, Requirements and Features
>>> ================================
>>>
>>> We presume that submissions will fulfill the applicable requirements of
>>> any boost submission.  In addition we would like to see the following
>>> addressed.
>>>
>>> Library Build
>>> -------------
>>>         “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
>>> Recommends that all libraries - including header only libraries have a
>>> CMakeList.txt file.  What should this include for Boost Libraries?
>>>
>>>
>>> Library Test
>>> ------------
>>>       Should facilities for "testing" be only done by developers? or
>>> should users who acquire library packages also be able to test libraries.
>>>       Should CMake testing results posting be used - CDASH?
>>>       Should we just skip the issue of Library Testing and continue to
>>> depend on Boost Build.
>>>
>>> Library Packaging
>>> -----------------
>>>       Is the library packaging facility provide by CMake - CPACK - useful
>>> to boost.  Should boost libraries be updated to support it?
>>>
>>> Dependencies
>>> ------------
>>>       If the above is implemented, can we depend upon CMake to handle
>>> library dependencies?  Or does some special functionality
>>>       Do circular dependencies constitute a problem?
>>>
>>> Modularity
>>> ----------
>>>       Currently boost is organized as a tightly integrated group of
>>> libraries.  This organization manifests itself in a number of ways.
>>>           We have a Boost "super project" in github.  Boost libraries are
>>> "sub projects" of this super project.  This known structure is exploited
>>> by and depended upon by boost tools.  Should CMake support continue this
>>> policy/design.
>>>           We distribute boost as "super project".  Should we continue to
>>> do this or distribute libraries on a library by library basis.  Does
>>> CMake/CPACK etc. make this "simple"?
>>>
>>> Documentation/testing
>>> ---------------------
>>>       What support should be require for uses of Boost CMake
>>> implementation. Documentation, examples, templates for helping library
>>> developers.  How should the CMake design/implementation be tested?
>>>
>>> Other considerations
>>> --------------------
>>> add your requirement/features here.
>>>
>>>
>>> Useful Resources
>>> ===============
>>>       “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
>>>       https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
>>>       https://github.com/purpleKarrot/Boost.CMake
>>>       https://www.youtube.com/watch?v=eC9-iRN2b04
>>>
>>> Please try to keep this discussion on this list.
>>>
>>> I know that there has been a lot going on on slack. But having it in two
>>> places makes it harder for me to review and summarize.  Also slack
>>> doesn't conveniently maintain comment hierarchy.  So please try to keep
>>> this discussion on this list.
>>
>> I strongly suggest that the goal of using CMake with Boost begin with
>> making Boost libraries, whether header-only or built, available to CMake
>> projects. This also means that we have a way of testing whether or not
>> such a solution actually works for any given Boost library. My own
>> preference for testing whether or not such a solution would work or not
>> would be to use our current b2/Boost Build test jamfiles, but if this is
>> too difficult to do we still need some way to test the solution for each
>> library so each library maintainer can see whether or not the solution
>> we choose works for his library.
>>
>> This should be our first goal and all other goals should be tabled until
>> and when we can have a solution where this works flawlessly and there is
>> a general agreement that whatever proposal is chosen to implement this
>> is best.
>>
>> Only when the above is fully accomplished should Boost then look into
>> the goal of using CMake internally, perhaps for test, docs, building
>> libraries, or what-not. We need to work this way because every solution
>> is bound to end with comments that it does X but does not do Y or it
>> does X and Y but does not do Z, and we all know where these endless
>> arguments end: that we end up doing nothing because we start by trying
>> to do too much and we can never reach agreement.
>
> I agree with you in so far, that the focus should be on the interface
> (how to consume boost libraries) and less on the implementation details,
> but I see two practical reasons, why it is beneficial to immediately
> use cmake (at least) for building too:
>
> 1) Creating a CMake target for a separately compiled binary that can be
>     consumed by the user is about the same effort as using cmake to build
>     the library (if necessary) in which case you get the interface
>     information for free (switching to cmake for unit-tests and docs is a
>     different topic).
>  
> 2) "making Boost libraries [...] available to CMake projects" for me also
>     means I have an easy way to compile those libraries with specific
>     compiler flags that match my project settings - otherwise, what is the
>     advantage compared to the current mechanism that is already build into
>     cmake?
>     Ensuring consistent build flags is relatively easy if all libraries use
>     the same build system (in this case cmake) but can become quite complex
>     if you want to implement an automatic translation from cmake to b2 or
>     vice versa.
>
> So yes, while a library (build-) interface and consummation should be the
> focus of the review, I'd expect that at least building the libraries with
> cmake will be the simplest way to implement that interface.
>
> Just to be completely clear: Just because the "reference implementation"
> of a cmake interface is probably a cmake-based build, that doesn't mean
> everyone has to actually adopt that reference implementation as long as
> the interface is consistent.

Boost Build has a feature which allows the programmer to test at build
time what C++ features are supported for a particular compiler
implementation and compile parameters, and change the build internally
on-the-fly accordingly. I do not know if any Boost non-header only
library uses this feature but if one does it will be difficult
translating this to CMake terms, if such a similar feature exists in CMake.

It is for such a reason that as soon as you start talking about using
CMake for anything else but identifying Boost libraries for the purposes
of end-user use of Boost libraries in their own CMake scripts, that you
may run into much more work than you can imagine. You just can't tell
individual library developers to translate all their own use of Boost
Build into CMake, as if this will be simple for them to do, and they
will just do it with little time spent and as if it will be no work for
them. Boost Build, for better or worse, has some extensive features
which have no easy correspondence to CMake. Unless you or someone else
is willing to develop a bridge between Boost Build and CMake for
features of Boost Build which libraries rely on, then individual Boost
libraries which use such Boost Build features are going to find it very
difficult to transition to CMake, possibly even for something as
seemingly innocuous as building the library itself using a CMake script.

This is why I have urged the move to CMake by Boost to proceed slowly by
baby steps, rather than to try doing things that may take a huge initial
effort to get done, and therefore may end up never accomplishing anything.

>
> Mike


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In article <ppge4m$2d5$[hidden email]>,
    Edward Diener via Boost <[hidden email]> writes:

> Boost Build has a feature which allows the programmer to test at build
> time what C++ features are supported for a particular compiler
> implementation and compile parameters, and change the build internally
> on-the-fly accordingly. I do not know if any Boost non-header only
> library uses this feature but if one does it will be difficult
> translating this to CMake terms, if such a similar feature exists in CMake.

CMake has supported this for years, it is not a blocking issue.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On 10/8/2018 6:46 PM, Richard via Boost wrote:

> In article <ppge4m$2d5$[hidden email]>,
>      Edward Diener via Boost <[hidden email]> writes:
>
>> Boost Build has a feature which allows the programmer to test at build
>> time what C++ features are supported for a particular compiler
>> implementation and compile parameters, and change the build internally
>> on-the-fly accordingly. I do not know if any Boost non-header only
>> library uses this feature but if one does it will be difficult
>> translating this to CMake terms, if such a similar feature exists in CMake.
>
> CMake has supported this for years, it is not a blocking issue.

Good ! Then I am sure you will be glad to be nominated as the person who
converts all instances of the Boost Build use of this feature, in any
Boost library which uses it, to the exact equivalent in CMake. It is
great to know that you have volunteered to do this for Boost !



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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In article <ppgt9u$6a1$[hidden email]>,
    Edward Diener via Boost <[hidden email]> writes:

> Good ! Then I am sure you will be glad to be nominated as the person who
> converts all instances of the Boost Build use of this feature,

You can nominate about whatever you like, but I am not volunteering
for anything in boost.  It takes forever to get anything done.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On 2018-10-09 05:13 PM, Richard via Boost wrote:

> In article <ppgt9u$6a1$[hidden email]>,
>      Edward Diener via Boost <[hidden email]> writes:
>
>> Good ! Then I am sure you will be glad to be nominated as the person who
>> converts all instances of the Boost Build use of this feature,
> You can nominate about whatever you like, but I am not volunteering
> for anything in boost.  It takes forever to get anything done.

I think the point wasn't so much to nominate you, but rather to point
out that a statement like the one you made is rater gratuitous to make
if you don't have to back it up by actually doing the implied work.

Stefan

--

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


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Let me start by thanking you, Robert, for getting this process
started. CMake has been a hot topic for a long time with little action
and getting a review going is important.

On Mon, Oct 1, 2018 at 8:07 PM Robert Ramey via Boost
<[hidden email]> wrote:
>
> Scope, Requirements and Features
> ================================
>
> Library Build
> -------------
>         “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
> Recommends that all libraries - including header only libraries have a
> CMakeList.txt file.  What should this include for Boost Libraries?

I suppose, every library, header-only or not, will have to include
CMakeLists.txt. For separately compiled libraries, CMakeLists.txt
should support building the library, similarly to Boost.Build. These
CMakeLists.txt files, along with the one of the superproject, will
have to be included in the source code packages we distribute. And
also in the Windows binary packages we distribute.

Note that here I assume that at this point we are continuing to
distribute monolithic Boost releases for the time being. This may
change in the future as we modularize Boost but for now having CMake
alone is a big enough task by itself. Of course, if a certain CMake
proposal already presents a potential route for further
modularization, it can only be a plus.

> Library Test
> ------------
>         Should facilities for "testing" be only done by developers? or should
> users who acquire library packages also be able to test libraries.

I think, the ability to test libraries is essential for both Boost
developers and users (primarily, developers, though). I think,
potential solutions should include this functionality.

>         Should CMake testing results posting be used - CDASH?

I don't really know what CDash is, I've never used it.

>         Should we just skip the issue of Library Testing and continue to depend
> on Boost Build.

Building library docs is missing in this section. Having CMake able to
build docs is less important than being able to build and test
libraries, so we may omit this functionality at first. Docs are
available online and pretty readable in source form most of the time.
However, it would seem that this task should be the easiest one from
the build system standpoint, so it shouldn't be too difficult to add.

> Library Packaging
> -----------------
>         Is the library packaging facility provide by CMake - CPACK - useful to
> boost.  Should boost libraries be updated to support it?

I would really like us to not get into the packaging business beyond
preparing source packages of Boost releases. Packaging is a difficult
topic, very target system dependent. Let the people who has the domain
knowledge do it.

As someone who has built Debian packages of Boost for my project I can
tell that it is unlikely that I would use CPack. Not because something
is wrong with it (in fact, I've never had to use it, so I really don't
know), but because the current building pipeline doesn't involve it
and works backwards. I.e., as far as I know, CPack is designed to be
part of the build system, to which it adds packaging as one of the
steps, while the common workflow is that you invoke packaging tools
(dpkg, debhelper in case of Debian packages), which invokes the build
process and then collects and packages the artifacts from it. I don't
really see the benefit from changing the common workflow.

I suppose, CPack could be useful if we did packaging and deploy as
part of our CI process, but we don't.

> Dependencies
> ------------
>         If the above is implemented, can we depend upon CMake to handle library
> dependencies?  Or does some special functionality
>         Do circular dependencies constitute a problem?

I think, dependency management will be limited to enumerating
immediate dependencies for the targets in CMakeLists.txt, much like
what we have now with Boost.Build. Since we won't do packaging, we
won't have to deal with package dependencies, including dependencies
from system libraries, like zlib, for example.

I'm not sure how CMake manages dependencies between targets and
whether circular dependencies constitute a problem. CMake proposals
will have to clarify that, I guess.

> Modularity
> ----------
>         Currently boost is organized as a tightly integrated group of
> libraries.  This organization manifests itself in a number of ways.
>                 We have a Boost "super project" in github.  Boost libraries are "sub
> projects" of this super project.  This known structure is exploited by
> and depended upon by boost tools.  Should CMake support continue this
> policy/design.
>                 We distribute boost as "super project".  Should we continue to do this
> or distribute libraries on a library by library basis.  Does CMake/CPACK
> etc. make this "simple"?

As I said earlier, I don't think we should specifically target
modilarization at this point as just adding support for CMake alone is
a big enough task. Let us leave further modularization for future and
not require immediate support for it.

Therefore, I think, we will have a CMakeLists.txt in the superproject,
as well as in the libs directory.

> Documentation/testing
> ---------------------
>         What support should be require for uses of Boost CMake implementation.
> Documentation, examples, templates for helping library developers.  How
> should the CMake design/implementation be tested?

I think, documentation and examples are required. Given that,
presumably, library maintainers will be the ones who will have to
write CMakeLists.txt for their libraries, the docs quality is very
important. Besides the obvious stuff, like how to create a library or
a test, the docs should describe more intricate stuff, like how to add
compiler switches depending on compiler or how to test if the compiler
supports a certain feature and do something depending on that, or how
to set a custom visibility for a project, etc. From experience with
Boost.Build, I can say that it is these little details that are
difficult to find out.

It would help if, as a proof of concept, demonstrated one or two
converted libraries which cover most common and more inticate use
cases we have.

As for tests, these are, of course, welcome, but ultimately it is the
tool that helps the maintainer most, so I'd leave this to the authors'
discretion. I'm not even sure how one would test CMake scripts.

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

Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Edward Diener via
> Boost
> Sent: Monday, October 8, 2018 10:22 PM
>
> On 10/8/2018 6:15 AM, Mike Dev via Boost wrote:
> >> -----Original Message-----
> >> From: Boost <[hidden email]> On Behalf Of Edward Diener
> >> via Boost
> >> Sent: Monday, October 1, 2018 8:00 PM
> >>
> >> On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:
> >>> Background
> >>> ==========
> >>>
> >>> My personal knowledge of build systems is somewhat limited.
> >>>
> >>> a) I don't really understand CMake all that well.  I have made
> >>> CMakeLists.txt files for both the serialization library and the safe
> >>> numerics libraries as an aid to build and maintain IDE and make files
> >>> used in running tests and posting results to CDash.
> >>>
> >>> b) I don't really understand our current system, Boost Build, very
> >>> well
> >>> either.  I've made jam files for building and running tests for the
> >>> serialization and safe numerics libraries.
> >>>
> >>> c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
> >>> from C++Now 2017  “Effective CMake" -
> >>> https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
> >>>
> >>> Despite my lack of knowledge in this area, or perhaps because of it,
> >>> I've volunteered to direct the effort to evolve Boost so that users of
> >>> Boost can avail themselves of the benefits of CMake.  This effort will
> >>> be organized as follows:
> >>>
> >>> a) A discussion on the boost developers mailing list with the goal of
> >>> reaching a consensus as to what benefits CMake can and should provide
> >>> to
> >>> users and developers of Boost.  This effort will commence with the
> >>> posting of this notice.  I hope that this discussion can be more or
> >>> less
> >>> resolved within 30 days.
> >>>
> >>> b) I will then synthesize from the above discussion a call for
> >>> proposals
> >>> which lists the requirements and requirements.
> >>>
> >>> c) Those proposing CMake for boost will have approximately 90 days to
> >>> prepare their proposals.  Their proposal are expected to look similar
> >>> to
> >>> a boost library proposal.  That is they are expected to have some
> >>> (CMake) code, along with tests, documentation including tutorials and
> >>> reference.  This is only an expectation.  It's conceivable that such a
> >>> proposal might only contain conventions and and samples of what boost
> >>> library should contain to fulfill the requirements. As with boost
> >>> libraries, submissions are not required to totally complete.  But they
> >>> have to be sufficiently complete to convince reviewers the the
> >>> submission fulfills the stated requirements and can be finished in
> >>> good
> >>> time.
> >>>
> >>> d) After the 90 day period, submissions will be reviewed
> >>> simultaneously.
> >>>    Note that this is at a variance from normal boost procedure of
> >>> reviewing submissions one at a time.  Since we expect to receive a
> >>> number of submissions and only one can be accepted, the normal boost
> >>> protocol can't really function.  Target date for this review is 1
> >>> February 2019.
> >>>
> >>> e) After the review period the review manager will prepare a report
> >>> which includes the decision of which submission will be accepted into
> >>> the official boost distribution.  Currently, I, Robert Ramey, expect
> >>> to
> >>> be review manager.  However, it's possible that this by the time the
> >>> review is undertaken, this coveted position could be assigned to some
> >>> more worthy candidate.
> >>>
> >>> Scope, Requirements and Features
> >>> ================================
> >>>
> >>> We presume that submissions will fulfill the applicable requirements
> >>> of
> >>> any boost submission.  In addition we would like to see the following
> >>> addressed.
> >>>
> >>> Library Build
> >>> -------------
> >>>         “Effective CMake" -
> >>> https://www.youtube.com/watch?v=bsXLMQ6WgIk
> >>> Recommends that all libraries - including header only libraries have a
> >>> CMakeList.txt file.  What should this include for Boost Libraries?
> >>>
> >>>
> >>> Library Test
> >>> ------------
> >>>       Should facilities for "testing" be only done by developers? or
> >>> should users who acquire library packages also be able to test
> >>> libraries.
> >>>       Should CMake testing results posting be used - CDASH?
> >>>       Should we just skip the issue of Library Testing and continue to
> >>> depend on Boost Build.
> >>>
> >>> Library Packaging
> >>> -----------------
> >>>       Is the library packaging facility provide by CMake - CPACK -
> >>> useful
> >>> to boost.  Should boost libraries be updated to support it?
> >>>
> >>> Dependencies
> >>> ------------
> >>>       If the above is implemented, can we depend upon CMake to handle
> >>> library dependencies?  Or does some special functionality
> >>>       Do circular dependencies constitute a problem?
> >>>
> >>> Modularity
> >>> ----------
> >>>       Currently boost is organized as a tightly integrated group of
> >>> libraries.  This organization manifests itself in a number of ways.
> >>>           We have a Boost "super project" in github.  Boost libraries
> >>> are
> >>> "sub projects" of this super project.  This known structure is
> >>> exploited
> >>> by and depended upon by boost tools.  Should CMake support continue
> >>> this
> >>> policy/design.
> >>>           We distribute boost as "super project".  Should we continue
> >>> to
> >>> do this or distribute libraries on a library by library basis.  Does
> >>> CMake/CPACK etc. make this "simple"?
> >>>
> >>> Documentation/testing
> >>> ---------------------
> >>>       What support should be require for uses of Boost CMake
> >>> implementation. Documentation, examples, templates for helping library
> >>> developers.  How should the CMake design/implementation be tested?
> >>>
> >>> Other considerations
> >>> --------------------
> >>> add your requirement/features here.
> >>>
> >>>
> >>> Useful Resources
> >>> ===============
> >>>       “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
> >>>       https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
> >>>       https://github.com/purpleKarrot/Boost.CMake
> >>>       https://www.youtube.com/watch?v=eC9-iRN2b04
> >>>
> >>> Please try to keep this discussion on this list.
> >>>
> >>> I know that there has been a lot going on on slack. But having it in
> >>> two
> >>> places makes it harder for me to review and summarize.  Also slack
> >>> doesn't conveniently maintain comment hierarchy.  So please try to
> >>> keep
> >>> this discussion on this list.
> >>
> >> I strongly suggest that the goal of using CMake with Boost begin with
> >> making Boost libraries, whether header-only or built, available to
> >> CMake
> >> projects. This also means that we have a way of testing whether or not
> >> such a solution actually works for any given Boost library. My own
> >> preference for testing whether or not such a solution would work or not
> >> would be to use our current b2/Boost Build test jamfiles, but if this
> >> is
> >> too difficult to do we still need some way to test the solution for
> >> each
> >> library so each library maintainer can see whether or not the solution
> >> we choose works for his library.
> >>
> >> This should be our first goal and all other goals should be tabled
> >> until
> >> and when we can have a solution where this works flawlessly and there
> >> is
> >> a general agreement that whatever proposal is chosen to implement this
> >> is best.
> >>
> >> Only when the above is fully accomplished should Boost then look into
> >> the goal of using CMake internally, perhaps for test, docs, building
> >> libraries, or what-not. We need to work this way because every solution
> >> is bound to end with comments that it does X but does not do Y or it
> >> does X and Y but does not do Z, and we all know where these endless
> >> arguments end: that we end up doing nothing because we start by trying
> >> to do too much and we can never reach agreement.
> >
> > I agree with you in so far, that the focus should be on the interface
> > (how to consume boost libraries) and less on the implementation details,
> > but I see two practical reasons, why it is beneficial to immediately
> > use cmake (at least) for building too:
> >
> > 1) Creating a CMake target for a separately compiled binary that can be
> >     consumed by the user is about the same effort as using cmake to
> > build
> >     the library (if necessary) in which case you get the interface
> >     information for free (switching to cmake for unit-tests and docs is
> > a
> >     different topic).
> >
> > 2) "making Boost libraries [...] available to CMake projects" for me
> > also
> >     means I have an easy way to compile those libraries with specific
> >     compiler flags that match my project settings - otherwise, what is
> > the
> >     advantage compared to the current mechanism that is already build
> > into
> >     cmake?
> >     Ensuring consistent build flags is relatively easy if all libraries
> > use
> >     the same build system (in this case cmake) but can become quite
> > complex
> >     if you want to implement an automatic translation from cmake to b2
> > or
> >     vice versa.
> >
> > So yes, while a library (build-) interface and consummation should be
> > the
> > focus of the review, I'd expect that at least building the libraries
> > with
> > cmake will be the simplest way to implement that interface.
> >
> > Just to be completely clear: Just because the "reference implementation"
> > of a cmake interface is probably a cmake-based build, that doesn't mean
> > everyone has to actually adopt that reference implementation as long as
> > the interface is consistent.
>
> Boost Build has a feature which allows the programmer to test at build
> time what C++ features are supported for a particular compiler
> implementation and compile parameters, and change the build internally
> on-the-fly accordingly. I do not know if any Boost non-header only
> library uses this feature but if one does it will be difficult
> translating this to CMake terms, if such a similar feature exists in
> CMake.

As Richard pointed out, such features exist in cmake too and have been in
common use for years. E.g. It has a built-in mechanism that lets you
directly query for most of the post c++03 compiler features:
(https://cmake.org/cmake/help/v3.13/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html)
and as a more general feature, you can always check if a particular source
file using some feature or type compiles or not:
(https://cmake.org/cmake/help/v3.13/module/CheckCXXSourceCompiles.html)

Could you maybe point me to some examples where this feature is used so one
could estimate how difficult a conversion is?

> It is for such a reason that as soon as you start talking about using
> CMake for anything else but identifying Boost libraries for the purposes
> of end-user use of Boost libraries in their own CMake scripts,

Just consuming precompiled/pre-installed boost libraries in a cmake script
is already possible thanks to the work of cmake contributors and the people
providing boost packages for vcpkg, conan and other package management
systems (some of those contributors are probably also boost library
maintainers?).
Those solutions have to keep playing catch up with the latest boost
release if something significant changes (like name-mangling or a new
library), but by and large they work quite well. Imho an official boost
 solution should provide a bit more functionality to justify the effort.

> that you
> may run into much more work than you can imagine. You just can't tell
> individual library developers to translate all their own use of Boost
> Build into CMake, as if this will be simple for them to do, and they
> will just do it with little time spent and as if it will be no work for
> them.

Let's get one thing straight: Switching to cmake will require work, no
one is denying that and it will not happen during the course of a single
release. And if library developers are not willing to invest some time to
do this, we can forget about it all together. However, it is my impression
that many developers are willing to make that effort. All that is lacking
is a clear decision of what the (semi-) final solution should look like to
make sure the effort isn't wasted.

Now as I said. I'm not convinced, that only providing interface information
is actually less work than building boost with cmake and letting it generate
the cmake information automatically. That probably depends to a large degree
if those cmake files can be auto generated by b2. However, just as there
seem to be more complex build scenarios, there are probably scenarios where
the auto-generated cmake-config files are not enough.

> Boost Build, for better or worse, has some extensive features
> which have no easy correspondence to CMake.

Such as? If plain cmake is lacking any important features that are needed
by boost, then a replacement is exactly what a boost cmake library should
provide.

> Unless you or someone else
> is willing to develop a bridge between Boost Build and CMake for
> features of Boost Build which libraries rely on, then individual Boost
> libraries which use such Boost Build features are going to find it very
> difficult to transition to CMake, possibly even for something as
> seemingly innocuous as building the library itself using a CMake script.

Let's not forget, that there are already solutions out there that build
(almost?) all of boost with cmake. Here is one:
https://github.com/boost-cmake/boost

Now instead of adopting and tweaking one of those existing solutions during
review, you are imho asking for the development of yet another solution. I'm
not sure if that is actually an easier path forward.
That doesn't mean that an individual library author can't decide he wants
to stick to b2 internally and just provide a cmake interface file, but we
for the time being and

>
> This is why I have urged the move to CMake by Boost to proceed slowly by
> baby steps, rather than to try doing things that may take a huge initial
> effort to get done, and therefore may end up never accomplishing anything.

That is kind of what I'm trying to achieve with my individual mini PRs. They
are in no way a replacement for the existing boost build system, as they
only cover a very narrow use case, but even those also build the boost libraries.
Again, I don't think building is the issue (as I said, it has been done already)
and if someone really encounters a problem, I'm sure people on the ML and
elsewhere are willing to help. IMHO it will be far more difficult to agree
all the bike shedding topics related to how exactly boost libraries should be
made available to the consumer.

Also, proceeding by Baby steps means that boost will stay in limbo between
cmake and boost build for quite some time, where library maintainers will
have to maintain two systems and more or less constantly upgrading their
CMake files. It doesn't have to happen all in one big step (I agree that that
is not realistic), but considering that consumers can already use boost
libraries in their cmake projects (albeit with a few pain points here and there)
and that there are already proof of concepts for more fully fledged solutions
out there, I think the initial goal should be a tad more ambitious.


Mike


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/8/18 5:40 PM, Edward Diener via Boost wrote:

> On 10/8/2018 6:46 PM, Richard via Boost wrote:
>> In article <ppge4m$2d5$[hidden email]>,
>>      Edward Diener via Boost <[hidden email]> writes:
>>
>>> Boost Build has a feature which allows the programmer to test at build
>>> time what C++ features are supported for a particular compiler
>>> implementation and compile parameters, and change the build internally
>>> on-the-fly accordingly. I do not know if any Boost non-header only
>>> library uses this feature but if one does it will be difficult
>>> translating this to CMake terms, if such a similar feature exists in
>>> CMake.
>>
>> CMake has supported this for years, it is not a blocking issue.
>
> Good ! Then I am sure you will be glad to be nominated as the person who
> converts all instances of the Boost Build use of this feature, in any
> Boost library which uses it, to the exact equivalent in CMake. It is
> great to know that you have volunteered to do this for Boost !

I don't think that at this point you can presume that such a person
would be necessary.  But then again I don't presume it wouldn't either.

I'm going restate this as a suggested requirement:

"Any new CMake implemenation for Boost shouldn't require non-trivial
efforts on existing libraries by library developers."

I'll take this under advisement.

Robert Ramey


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/9/2018 7:09 PM, mike via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Edward Diener via
>> Boost
>> Sent: Monday, October 8, 2018 10:22 PM
>>
>> On 10/8/2018 6:15 AM, Mike Dev via Boost wrote:
>>>> -----Original Message-----
>>>> From: Boost <[hidden email]> On Behalf Of Edward Diener
>>>> via Boost
>>>> Sent: Monday, October 1, 2018 8:00 PM
>>>>
>>>> On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:
>>>>> Background
>>>>> ==========
>>>>>
>>>>> My personal knowledge of build systems is somewhat limited.
>>>>>
>>>>> a) I don't really understand CMake all that well.  I have made
>>>>> CMakeLists.txt files for both the serialization library and the safe
>>>>> numerics libraries as an aid to build and maintain IDE and make files
>>>>> used in running tests and posting results to CDash.
>>>>>
>>>>> b) I don't really understand our current system, Boost Build, very
>>>>> well
>>>>> either.  I've made jam files for building and running tests for the
>>>>> serialization and safe numerics libraries.
>>>>>
>>>>> c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
>>>>> from C++Now 2017  “Effective CMake" -
>>>>> https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
>>>>>
>>>>> Despite my lack of knowledge in this area, or perhaps because of it,
>>>>> I've volunteered to direct the effort to evolve Boost so that users of
>>>>> Boost can avail themselves of the benefits of CMake.  This effort will
>>>>> be organized as follows:
>>>>>
>>>>> a) A discussion on the boost developers mailing list with the goal of
>>>>> reaching a consensus as to what benefits CMake can and should provide
>>>>> to
>>>>> users and developers of Boost.  This effort will commence with the
>>>>> posting of this notice.  I hope that this discussion can be more or
>>>>> less
>>>>> resolved within 30 days.
>>>>>
>>>>> b) I will then synthesize from the above discussion a call for
>>>>> proposals
>>>>> which lists the requirements and requirements.
>>>>>
>>>>> c) Those proposing CMake for boost will have approximately 90 days to
>>>>> prepare their proposals.  Their proposal are expected to look similar
>>>>> to
>>>>> a boost library proposal.  That is they are expected to have some
>>>>> (CMake) code, along with tests, documentation including tutorials and
>>>>> reference.  This is only an expectation.  It's conceivable that such a
>>>>> proposal might only contain conventions and and samples of what boost
>>>>> library should contain to fulfill the requirements. As with boost
>>>>> libraries, submissions are not required to totally complete.  But they
>>>>> have to be sufficiently complete to convince reviewers the the
>>>>> submission fulfills the stated requirements and can be finished in
>>>>> good
>>>>> time.
>>>>>
>>>>> d) After the 90 day period, submissions will be reviewed
>>>>> simultaneously.
>>>>>     Note that this is at a variance from normal boost procedure of
>>>>> reviewing submissions one at a time.  Since we expect to receive a
>>>>> number of submissions and only one can be accepted, the normal boost
>>>>> protocol can't really function.  Target date for this review is 1
>>>>> February 2019.
>>>>>
>>>>> e) After the review period the review manager will prepare a report
>>>>> which includes the decision of which submission will be accepted into
>>>>> the official boost distribution.  Currently, I, Robert Ramey, expect
>>>>> to
>>>>> be review manager.  However, it's possible that this by the time the
>>>>> review is undertaken, this coveted position could be assigned to some
>>>>> more worthy candidate.
>>>>>
>>>>> Scope, Requirements and Features
>>>>> ================================
>>>>>
>>>>> We presume that submissions will fulfill the applicable requirements
>>>>> of
>>>>> any boost submission.  In addition we would like to see the following
>>>>> addressed.
>>>>>
>>>>> Library Build
>>>>> -------------
>>>>>          “Effective CMake" -
>>>>> https://www.youtube.com/watch?v=bsXLMQ6WgIk
>>>>> Recommends that all libraries - including header only libraries have a
>>>>> CMakeList.txt file.  What should this include for Boost Libraries?
>>>>>
>>>>>
>>>>> Library Test
>>>>> ------------
>>>>>        Should facilities for "testing" be only done by developers? or
>>>>> should users who acquire library packages also be able to test
>>>>> libraries.
>>>>>        Should CMake testing results posting be used - CDASH?
>>>>>        Should we just skip the issue of Library Testing and continue to
>>>>> depend on Boost Build.
>>>>>
>>>>> Library Packaging
>>>>> -----------------
>>>>>        Is the library packaging facility provide by CMake - CPACK -
>>>>> useful
>>>>> to boost.  Should boost libraries be updated to support it?
>>>>>
>>>>> Dependencies
>>>>> ------------
>>>>>        If the above is implemented, can we depend upon CMake to handle
>>>>> library dependencies?  Or does some special functionality
>>>>>        Do circular dependencies constitute a problem?
>>>>>
>>>>> Modularity
>>>>> ----------
>>>>>        Currently boost is organized as a tightly integrated group of
>>>>> libraries.  This organization manifests itself in a number of ways.
>>>>>            We have a Boost "super project" in github.  Boost libraries
>>>>> are
>>>>> "sub projects" of this super project.  This known structure is
>>>>> exploited
>>>>> by and depended upon by boost tools.  Should CMake support continue
>>>>> this
>>>>> policy/design.
>>>>>            We distribute boost as "super project".  Should we continue
>>>>> to
>>>>> do this or distribute libraries on a library by library basis.  Does
>>>>> CMake/CPACK etc. make this "simple"?
>>>>>
>>>>> Documentation/testing
>>>>> ---------------------
>>>>>        What support should be require for uses of Boost CMake
>>>>> implementation. Documentation, examples, templates for helping library
>>>>> developers.  How should the CMake design/implementation be tested?
>>>>>
>>>>> Other considerations
>>>>> --------------------
>>>>> add your requirement/features here.
>>>>>
>>>>>
>>>>> Useful Resources
>>>>> ===============
>>>>>        “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk
>>>>>        https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
>>>>>        https://github.com/purpleKarrot/Boost.CMake
>>>>>        https://www.youtube.com/watch?v=eC9-iRN2b04
>>>>>
>>>>> Please try to keep this discussion on this list.
>>>>>
>>>>> I know that there has been a lot going on on slack. But having it in
>>>>> two
>>>>> places makes it harder for me to review and summarize.  Also slack
>>>>> doesn't conveniently maintain comment hierarchy.  So please try to
>>>>> keep
>>>>> this discussion on this list.
>>>>
>>>> I strongly suggest that the goal of using CMake with Boost begin with
>>>> making Boost libraries, whether header-only or built, available to
>>>> CMake
>>>> projects. This also means that we have a way of testing whether or not
>>>> such a solution actually works for any given Boost library. My own
>>>> preference for testing whether or not such a solution would work or not
>>>> would be to use our current b2/Boost Build test jamfiles, but if this
>>>> is
>>>> too difficult to do we still need some way to test the solution for
>>>> each
>>>> library so each library maintainer can see whether or not the solution
>>>> we choose works for his library.
>>>>
>>>> This should be our first goal and all other goals should be tabled
>>>> until
>>>> and when we can have a solution where this works flawlessly and there
>>>> is
>>>> a general agreement that whatever proposal is chosen to implement this
>>>> is best.
>>>>
>>>> Only when the above is fully accomplished should Boost then look into
>>>> the goal of using CMake internally, perhaps for test, docs, building
>>>> libraries, or what-not. We need to work this way because every solution
>>>> is bound to end with comments that it does X but does not do Y or it
>>>> does X and Y but does not do Z, and we all know where these endless
>>>> arguments end: that we end up doing nothing because we start by trying
>>>> to do too much and we can never reach agreement.
>>>
>>> I agree with you in so far, that the focus should be on the interface
>>> (how to consume boost libraries) and less on the implementation details,
>>> but I see two practical reasons, why it is beneficial to immediately
>>> use cmake (at least) for building too:
>>>
>>> 1) Creating a CMake target for a separately compiled binary that can be
>>>      consumed by the user is about the same effort as using cmake to
>>> build
>>>      the library (if necessary) in which case you get the interface
>>>      information for free (switching to cmake for unit-tests and docs is
>>> a
>>>      different topic).
>>>
>>> 2) "making Boost libraries [...] available to CMake projects" for me
>>> also
>>>      means I have an easy way to compile those libraries with specific
>>>      compiler flags that match my project settings - otherwise, what is
>>> the
>>>      advantage compared to the current mechanism that is already build
>>> into
>>>      cmake?
>>>      Ensuring consistent build flags is relatively easy if all libraries
>>> use
>>>      the same build system (in this case cmake) but can become quite
>>> complex
>>>      if you want to implement an automatic translation from cmake to b2
>>> or
>>>      vice versa.
>>>
>>> So yes, while a library (build-) interface and consummation should be
>>> the
>>> focus of the review, I'd expect that at least building the libraries
>>> with
>>> cmake will be the simplest way to implement that interface.
>>>
>>> Just to be completely clear: Just because the "reference implementation"
>>> of a cmake interface is probably a cmake-based build, that doesn't mean
>>> everyone has to actually adopt that reference implementation as long as
>>> the interface is consistent.
>>
>> Boost Build has a feature which allows the programmer to test at build
>> time what C++ features are supported for a particular compiler
>> implementation and compile parameters, and change the build internally
>> on-the-fly accordingly. I do not know if any Boost non-header only
>> library uses this feature but if one does it will be difficult
>> translating this to CMake terms, if such a similar feature exists in
>> CMake.
>
> As Richard pointed out, such features exist in cmake too and have been in
> common use for years. E.g. It has a built-in mechanism that lets you
> directly query for most of the post c++03 compiler features:
> (https://cmake.org/cmake/help/v3.13/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html)
> and as a more general feature, you can always check if a particular source
> file using some feature or type compiles or not:
> (https://cmake.org/cmake/help/v3.13/module/CheckCXXSourceCompiles.html)
>
> Could you maybe point me to some examples where this feature is used so one
> could estimate how difficult a conversion is?

The feature is essentially programmed by config and predef to provide
build-time testing of compiler support and testing of such things like
the OS versions and compiler versions etc. See
https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html 
for the explanation in config and
https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html 
for checking predef values at build time. The basics of the feature are
offered by Boost Build as explained at
https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.rules 
in reference to the check-target-builds rule. Plenty of libraries use
the feature during testing and I imagine that some of them may use the
feature during building. Asking individual libraries to convert their
tests or build to use some CMake equivalent, for every possible setting
in config and predef which they use, is not realistic. I understand that
CMake may have an equivalent technique, but who is going to program that
technique to offer all the equivalents which config and predef currently
offer ?

>
>> It is for such a reason that as soon as you start talking about using
>> CMake for anything else but identifying Boost libraries for the purposes
>> of end-user use of Boost libraries in their own CMake scripts,
>
> Just consuming precompiled/pre-installed boost libraries in a cmake script
> is already possible thanks to the work of cmake contributors and the people
> providing boost packages for vcpkg, conan and other package management
> systems (some of those contributors are probably also boost library
> maintainers?).
> Those solutions have to keep playing catch up with the latest boost
> release if something significant changes (like name-mangling or a new
> library), but by and large they work quite well. Imho an official boost
>   solution should provide a bit more functionality to justify the effort.
>
>> that you
>> may run into much more work than you can imagine. You just can't tell
>> individual library developers to translate all their own use of Boost
>> Build into CMake, as if this will be simple for them to do, and they
>> will just do it with little time spent and as if it will be no work for
>> them.
>
> Let's get one thing straight: Switching to cmake will require work, no
> one is denying that and it will not happen during the course of a single
> release. And if library developers are not willing to invest some time to
> do this, we can forget about it all together. However, it is my impression
> that many developers are willing to make that effort. All that is lacking
> is a clear decision of what the (semi-) final solution should look like to
> make sure the effort isn't wasted.
>
> Now as I said. I'm not convinced, that only providing interface information
> is actually less work than building boost with cmake and letting it generate
> the cmake information automatically. That probably depends to a large degree
> if those cmake files can be auto generated by b2. However, just as there
> seem to be more complex build scenarios, there are probably scenarios where
> the auto-generated cmake-config files are not enough.
>
>> Boost Build, for better or worse, has some extensive features
>> which have no easy correspondence to CMake.
>
> Such as? If plain cmake is lacking any important features that are needed
> by boost, then a replacement is exactly what a boost cmake library should
> provide.
>
>> Unless you or someone else
>> is willing to develop a bridge between Boost Build and CMake for
>> features of Boost Build which libraries rely on, then individual Boost
>> libraries which use such Boost Build features are going to find it very
>> difficult to transition to CMake, possibly even for something as
>> seemingly innocuous as building the library itself using a CMake script.
>
> Let's not forget, that there are already solutions out there that build
> (almost?) all of boost with cmake. Here is one:
> https://github.com/boost-cmake/boost
>
> Now instead of adopting and tweaking one of those existing solutions during
> review, you are imho asking for the development of yet another solution. I'm
> not sure if that is actually an easier path forward.
> That doesn't mean that an individual library author can't decide he wants
> to stick to b2 internally and just provide a cmake interface file, but we
> for the time being and
>
>>
>> This is why I have urged the move to CMake by Boost to proceed slowly by
>> baby steps, rather than to try doing things that may take a huge initial
>> effort to get done, and therefore may end up never accomplishing anything.
>
> That is kind of what I'm trying to achieve with my individual mini PRs. They
> are in no way a replacement for the existing boost build system, as they
> only cover a very narrow use case, but even those also build the boost libraries.
> Again, I don't think building is the issue (as I said, it has been done already)
> and if someone really encounters a problem, I'm sure people on the ML and
> elsewhere are willing to help. IMHO it will be far more difficult to agree
> all the bike shedding topics related to how exactly boost libraries should be
> made available to the consumer.
>
> Also, proceeding by Baby steps means that boost will stay in limbo between
> cmake and boost build for quite some time, where library maintainers will
> have to maintain two systems and more or less constantly upgrading their
> CMake files. It doesn't have to happen all in one big step (I agree that that
> is not realistic), but considering that consumers can already use boost
> libraries in their cmake projects (albeit with a few pain points here and there)
> and that there are already proof of concepts for more fully fledged solutions
> out there, I think the initial goal should be a tad more ambitious.
>
>
> Mike


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On Wed, Oct 10, 2018 at 2:43 AM Edward Diener via Boost
<[hidden email]> wrote:

>
> The feature is essentially programmed by config and predef to provide
> build-time testing of compiler support and testing of such things like
> the OS versions and compiler versions etc. See
> https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html
> for the explanation in config and
> https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html
> for checking predef values at build time. The basics of the feature are
> offered by Boost Build as explained at
> https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.rules
> in reference to the check-target-builds rule. Plenty of libraries use
> the feature during testing and I imagine that some of them may use the
> feature during building. Asking individual libraries to convert their
> tests or build to use some CMake equivalent, for every possible setting
> in config and predef which they use, is not realistic. I understand that
> CMake may have an equivalent technique, but who is going to program that
> technique to offer all the equivalents which config and predef currently
> offer ?

Why do you think a potential Boost.CMake proposal cannot offer an
equivalent of check-target-builds that internally uses the checks
based on Boost.Config or Boost.Predef? Because, AFAIU,
check-target-builds is exactly that - a compile test that involves a
preprocessor check of one of the macros + a bit of caching on
Boost.Build side. Doesn't sound like something that can't be done in
CMake.

As for the conversion process, I don't think it is reasonable to
expect a single person, a Boost.CMake candidate author, to convert all
Boost Jamfiles to CMake. Library authors *will* have to learn the new
build system and do the conversion of their libraries. Hopefully, a
proposed Boost.CMake should make it easier, but it won't be a free
ride.

PS: Also, let's not over-quote, please.

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/10/2018 12:09, mike wrote:

>> It is for such a reason that as soon as you start talking about using
>> CMake for anything else but identifying Boost libraries for the purposes
>> of end-user use of Boost libraries in their own CMake scripts,
>
> Just consuming precompiled/pre-installed boost libraries in a cmake script
> is already possible thanks to the work of cmake contributors and the people
> providing boost packages for vcpkg, conan and other package management
> systems (some of those contributors are probably also boost library
> maintainers?).
> Those solutions have to keep playing catch up with the latest boost
> release if something significant changes (like name-mangling or a new
> library), but by and large they work quite well. Imho an official boost
>   solution should provide a bit more functionality to justify the effort.

I'm mostly watching this from the sidelines (since other than building
Boost itself I use neither b2 nor cmake), so take this with a grain of
salt, but:

I think that "onboarding" the consumption of Boost libraries into Boost
could be valuable in itself with no need to justify additional
functionality, simply because it eliminates that catch-up process and
helps ensure things are correct before release instead of after.  And
Boost is probably in a better position to track library dependencies.

Having said that, I'm not sure how feasible it is in practice simply due
to historically package deployment being left entirely to outside
parties (especially on Linux), thus there being significant variation in
the wild.

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/9/18 4:58 PM, Andrey Semashev via Boost wrote:
>> in reference to the check-target-builds rule. Plenty of libraries use
>> the feature during testing and I imagine that some of them may use the
>> feature during building. Asking individual libraries to convert their
>> tests or build to use some CMake equivalent, for every possible setting
>> in config and predef which they use, is not realistic. I understand that
>> CMake may have an equivalent technique, but who is going to program that
>> technique to offer all the equivalents which config and predef currently
>> offer ?

At this point I have no idea what it might take for a CMake fulfill such
a requirement.  But of course that's not relevant at this point.

So this would be another suggested requirement:

"Build and Test should be able to adjust target requirements according
to the test results of boost/config - similar to how boost build does
today."

Again, This is noted.  I'll take it under advismment when I craft the
first cut of the "scope and requirements" proposal.

Robert Ramey


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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/10/2018 23:08, Andrey Semashev via Boost wrote:

>> Library Test
>> ------------
>>          Should facilities for "testing" be only done by developers? or should
>> users who acquire library packages also be able to test libraries.
>
> I think, the ability to test libraries is essential for both Boost
> developers and users (primarily, developers, though). I think,
> potential solutions should include this functionality.
>
>>          Should CMake testing results posting be used - CDASH?
>
> I don't really know what CDash is, I've never used it.

It's a "dashboard" which displays submitted test results.  It can be
used to aggregate testing on multiple platforms.

https://open.cdash.org/index.php?project=CMake is the dashboard for
CMake itself.

Boost could potentially use it, either the open dashboard or a
self-hosted one, but it's strictly optional.  Maybe Travis is
sufficient, or you could integrate something else entirely.

>> Library Packaging
>> -----------------
>>          Is the library packaging facility provide by CMake - CPACK - useful to
>> boost.  Should boost libraries be updated to support it?
>
> I would really like us to not get into the packaging business beyond
> preparing source packages of Boost releases. Packaging is a difficult
> topic, very target system dependent. Let the people who has the domain
> knowledge do it.
>
> As someone who has built Debian packages of Boost for my project I can
> tell that it is unlikely that I would use CPack. Not because something
> is wrong with it (in fact, I've never had to use it, so I really don't
> know), but because the current building pipeline doesn't involve it
> and works backwards.

Last time I tried it, it was inferior to the native packaging tools.
Particularly when packaging libraries, it didn't do as good a job with
library version dependencies--if you build Debian packages on a
non-Debian platform it can't compute the minimum library version from
shlibs.

I think it's primarily useful for packaging standalone applications
where there are no complex library dependencies.  Certainly for Windows
and MacOS X it makes sense.  For packaging a set of libraries like
Boost, I don't think it's as useful; we already have good Boost
packaging anyway, so I'd suggest ignoring it at least for now.


Regards,
Roger

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/10/2018 23:42, Edward Diener via Boost wrote:
> On 10/9/2018 7:09 PM, mike via Boost wrote:

>> As Richard pointed out, such features exist in cmake too and have been in
>> common use for years. E.g. It has a built-in mechanism that lets you
>> directly query for most of the post c++03 compiler features:
>> (https://cmake.org/cmake/help/v3.13/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html)
>>
>> and as a more general feature, you can always check if a particular
>> source
>> file using some feature or type compiles or not:
>> (https://cmake.org/cmake/help/v3.13/module/CheckCXXSourceCompiles.html)
>>
>> Could you maybe point me to some examples where this feature is used
>> so one
>> could estimate how difficult a conversion is?
>
> The feature is essentially programmed by config and predef to provide
> build-time testing of compiler support and testing of such things like
> the OS versions and compiler versions etc. See
> https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html 
> for the explanation in config and
> https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html 
> for checking predef values at build time. The basics of the feature are
> offered by Boost Build as explained at
> https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.rules 
> in reference to the check-target-builds rule. Plenty of libraries use
> the feature during testing and I imagine that some of them may use the
> feature during building. Asking individual libraries to convert their
> tests or build to use some CMake equivalent, for every possible setting
> in config and predef which they use, is not realistic. I understand that
> CMake may have an equivalent technique, but who is going to program that
> technique to offer all the equivalents which config and predef currently
> offer ?

This is all supported by CMake for years as mike said, and it's utterly
trivial to write such feature tests.  If you would like some examples,
here's some I wrote for Xerces-C++:

https://github.com/apache/xerces-c/tree/trunk/cmake

For example, here's a simple test for const [it's a port of Autoconf
logic] with CheckCXXSourceCompiles:
   https://github.com/apache/xerces-c/blob/trunk/cmake/XercesConst.cmake
this could be adapted for any feature you care to check, from constexpr
to user-defined literals, or any other feature which can be checked by
running the compiler.

This is a set of checks for integer type sizes:
https://github.com/apache/xerces-c/blob/trunk/cmake/XercesIntTypes.cmake

This is a more complex set of checks for SSE intrinsics:
https://github.com/apache/xerces-c/blob/trunk/cmake/XercesSSE2.cmake

Here's some checks to verify Boost is working properly:
https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/BoostChecks.cmake

Testing of linker version scripts:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L198

Checking include presence:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L212

Checking compiler keyword presence and fallbacks:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226

Checking structure presence:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226

Checking library symbol exports:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226


I don't think any of this is difficult.  If anything, you can likely
reuse the existing source code used by the Boost.Build checks, maybe
even sourced directly without any changes--just wrap it with
check_cxx_source_compiles or other feature test macros.


Regards,
Roger

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

Re: Boost CMake support - Request for Comment

Boost - Dev mailing list
On 10/10/2018 4:44 AM, Roger Leigh via Boost wrote:

> On 09/10/2018 23:42, Edward Diener via Boost wrote:
>> On 10/9/2018 7:09 PM, mike via Boost wrote:
>
>>> As Richard pointed out, such features exist in cmake too and have
>>> been in
>>> common use for years. E.g. It has a built-in mechanism that lets you
>>> directly query for most of the post c++03 compiler features:
>>> (https://cmake.org/cmake/help/v3.13/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html)
>>>
>>> and as a more general feature, you can always check if a particular
>>> source
>>> file using some feature or type compiles or not:
>>> (https://cmake.org/cmake/help/v3.13/module/CheckCXXSourceCompiles.html)
>>>
>>> Could you maybe point me to some examples where this feature is used
>>> so one
>>> could estimate how difficult a conversion is?
>>
>> The feature is essentially programmed by config and predef to provide
>> build-time testing of compiler support and testing of such things like
>> the OS versions and compiler versions etc. See
>> https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html 
>> for the explanation in config and
>> https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html 
>> for checking predef values at build time. The basics of the feature
>> are offered by Boost Build as explained at
>> https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.rules 
>> in reference to the check-target-builds rule. Plenty of libraries use
>> the feature during testing and I imagine that some of them may use the
>> feature during building. Asking individual libraries to convert their
>> tests or build to use some CMake equivalent, for every possible
>> setting in config and predef which they use, is not realistic. I
>> understand that CMake may have an equivalent technique, but who is
>> going to program that technique to offer all the equivalents which
>> config and predef currently offer ?
>
> This is all supported by CMake for years as mike said, and it's utterly
> trivial to write such feature tests.  If you would like some examples,
> here's some I wrote for Xerces-C++:
>
> https://github.com/apache/xerces-c/tree/trunk/cmake
>
> For example, here's a simple test for const [it's a port of Autoconf
> logic] with CheckCXXSourceCompiles:
>    https://github.com/apache/xerces-c/blob/trunk/cmake/XercesConst.cmake
> this could be adapted for any feature you care to check, from constexpr
> to user-defined literals, or any other feature which can be checked by
> running the compiler.
>
> This is a set of checks for integer type sizes:
> https://github.com/apache/xerces-c/blob/trunk/cmake/XercesIntTypes.cmake
>
> This is a more complex set of checks for SSE intrinsics:
> https://github.com/apache/xerces-c/blob/trunk/cmake/XercesSSE2.cmake
>
> Here's some checks to verify Boost is working properly:
> https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/BoostChecks.cmake 
>
>
> Testing of linker version scripts:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L198
>
> Checking include presence:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L212
>
> Checking compiler keyword presence and fallbacks:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
>
> Checking structure presence:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
>
> Checking library symbol exports:
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
>
>
> I don't think any of this is difficult.  If anything, you can likely
> reuse the existing source code used by the Boost.Build checks, maybe
> even sourced directly without any changes--just wrap it with
> check_cxx_source_compiles or other feature test macros.

My point is that you can not ask each library maintainer to re-invent
what he already uses from Boost config and/or Boost predef. You need to
reprogram this in CMake for each case in config and predef, and then
provide a CMake-like interface to it for other libraries. I do not care
how easy you find it in CMake, individual library maintainers are not
going to spend time re-duplicating everything they need from config and
predef just so they can build their library and/or run their library
tests. We are talking about some 130+ potential Boost libraries we have
to deal with, and any conversion to CMake that is non-trivial is going
to be very unpopular.


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