[cmake] Pull request announcement

classic Classic list List threaded Threaded
131 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: [cmake] Pull request announcement

Boost - Dev mailing list
On 9/14/2018 10:05 AM, Alexander Grund via Boost wrote:

> The major problem I see are the variants.
>
> - b2 can build multiple variants in one go (static, dynamic, runtimes...)
> - Encoding these variants has to be reflected in the target names/aliases
>
> CMake FindBoost solves this by requiring to set some variables to select
> a set of variants and set the appropriate aliases to this set.
>
> Think about how you reflect this in the CMake buildsystem. E.g. some
> libraries may depend explicitly on a static or dynamic version of
> another library (which can be expressed in bjam)
>
>> The practical problem for most libraries, which are largely
>> header-only, is converting the library jamfile for tests and building
>> docs into CMake terms. Building non-header only libraries is actually
>> much less of a problem for converting from Boost Build to CMake, even
>> if it will get the vast majority of the comments
> This won't be to bad either once the variants problem above is solved.
> CTest is quite powerful so except for a few corner cases I expect it to
> be straight forward.

CTest has absolutely no notion of compile-time testing. This was
mentioned to CMake on their mailing list a long time ago and got the
usual yawns from the CMake people.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:

> Edward Diener wrote:
>> On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:
>> > Dear all,
>> >
>> > unless I'm encountering an overwhelming resistance to this idea here
>> on > the ml, I intend to create a batch of PRs that introduce minimal
>> cmake > support to a large subset of boost libraries (maybe even all).
>>
>> The practical problem for most libraries, which are largely
>> header-only, is converting the library jamfile for tests and building
>> docs into CMake terms.
>
> That's not what the proposed minimal support is about (IIUC). The goal
> here is for people to be able to use a local installation of Boost (as
> cloned from Github, perhaps as a submodule) from their CMake projects by
> including the top-level CMakeLists.txt and then linking to the
> appropriate imported targets.
>
> Tests, docs, are not in scope. Neither is building multiple variants,
> staging, or installation.

In which case CMake support in Boost evidently means that Boost Build
will continue as the means to do tests and build the docs. That is fine
with me but must be understood by the Boost Steering Committee and Boost
developers/maintainers as part of Boost using CMake.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/14/18 11:02 AM, Edward Diener via Boost wrote:
>
> CTest has absolutely no notion of compile-time testing. This was
> mentioned to CMake on their mailing list a long time ago and got the
> usual yawns from the CMake people.

It can be done.  I needed for the CMake version of the script which runs
the tests for the safe numerics library.  It's a little kludgy.  But it
does work and it's inside the CMake black box so it solves the problem
in acceptable manner.

Robert Ramey

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


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/14/18 11:02 AM, Edward Diener via Boost wrote:

> CTest has absolutely no notion of compile-time testing. This was
> mentioned to CMake on their mailing list a long time ago and got the
> usual yawns from the CMake people.

Right. I needed this for the CMake testing of the safe numerics library.
  Found the hack to make it work.  A little kludgy be works find and is
inside the CMake black box so that's not really a problem.

Robert Ramey

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


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/14/18 11:05 AM, Edward Diener via Boost wrote:
> On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:
>> Edward Diener wrote:

>> That's not what the proposed minimal support is about (IIUC). The goal
>> here is for people to be able to use a local installation of Boost (as
>> cloned from Github, perhaps as a submodule) from their CMake projects
>> by including the top-level CMakeLists.txt and then linking to the
>> appropriate imported targets.
>>
>> Tests, docs, are not in scope. Neither is building multiple variants,
>> staging, or installation.
>
> In which case CMake support in Boost evidently means that Boost Build
> will continue as the means to do tests and build the docs. That is fine
> with me but must be understood by the Boost Steering Committee and Boost
> developers/maintainers as part of Boost using CMake.

Hmmm - Where is the scope defined? I don't think there is a concensus on
this.

Robert Ramey

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


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Peter Dimov
> Sent: Friday, September 14, 2018 6:52 PM
>
> mike wrote:
>
> > Frankly, I don't see the advantage to split such a trivial file:
>
> The advantage, as I already stated, is that when the dependencies change
> (which they do), you can just regenerate dependencies.cmake with
> boostdep
> (which can be automated) instead of editing CMakeLists.txt by hand.

Well, personally I think that is backwards: Taking a new dependency should be
a deliberate act that I manually document in my build file (many boost libraries
already have far too many internal dependencies). Only then do I start
to (directly) include headers from that dependency.  

But in the end, each library maintainer is of course free to reject / alter / extend
the cmake file I'm going to propose. Again, the only important thing is to have
a common naming convention for the public targets



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

[cmake] Pull request announcement

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: Friday, September 14, 2018 8:05 PM
> To: [hidden email]
> Cc: Edward Diener <[hidden email]>
> Subject: Re: [boost] [cmake] Pull request announcement
>
> On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:
> > Edward Diener wrote:
> >> On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:
> >> > Dear all,
> >> >
> >> > unless I'm encountering an overwhelming resistance to this idea here
> >> on > the ml, I intend to create a batch of PRs that introduce minimal
> >> cmake > support to a large subset of boost libraries (maybe even all).
> >>
> >> The practical problem for most libraries, which are largely
> >> header-only, is converting the library jamfile for tests and building
> >> docs into CMake terms.
> >
> > That's not what the proposed minimal support is about (IIUC). The goal
> > here is for people to be able to use a local installation of Boost (as
> > cloned from Github, perhaps as a submodule) from their CMake projects
> by
> > including the top-level CMakeLists.txt and then linking to the
> > appropriate imported targets.
> >
> > Tests, docs, are not in scope. Neither is building multiple variants,
> > staging, or installation.
>
> In which case CMake support in Boost evidently means that Boost Build
> will continue as the means to do tests and build the docs. That is fine
> with me but must be understood by the Boost Steering Committee and
> Boost
> developers/maintainers as part of Boost using CMake.
>

I'm pretty sure the desire of the steering committee, many users and probably
A lot of boost maintainers is that b2 gets completely replaced by a cmake based
solution someday (e.g. in the form of BCM).

However, I as a user would be very happy to at least have a solution that covers
80% of my use cases and that can be implemented now (by me alone if necessary)
 instead of further hoping that this full replacement comes "soon"


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

[cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Stefan Seefeld via Boost
> Sent: Friday, September 14, 2018 7:43 PM
>
> On 2018-09-14 12:14 PM, mike via Boost wrote:
>
> [...]
> Sorry, that never worked. New tools and processes appear (and disappear
> !) all the time. That's no reason to impose on any project maintainer to
> switch to whatever is en vogue.

Actually, it works quite well outside of boost. As I said, we are not talking
about following the latest hype here but the de-facto standard for
cross-platform C++ projects.

> Again, I'm not arguing for or against a specific set of tools. I'm
> arguing against the very idea to force >150 projects to adopt the same.

Imho, as long as boost tries to provide a joint release and distribution
mechanism and there is such a tight coupling between the libs,
at least the public interface (how do I tell a library, which compiler
and flags to use and how does a library tell me what it's dependencies are)
should be standardized just as it is now.

Also, far more than 150 Projects have adopted cmake (or at least provide
a cmake interface).

>
> So, to get back to the original announcement: all your effort and good
> intentions notwithstanding, I believe you shouldn't even try to
> contribute such infrastructure, unless of course your are fully
> committing to maintain it all, i.e. allow me to forward each and every
> bug report I'm going to receive on my projects that is related to that
> build logic.

As long as we are talking about genuine bug reports and not
feature request:  Sure
 
> Stefan

Mike


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
On 09/14/18 13:44, Mike Dev via Boost wrote:

> This will not address
> - Testing
[...]
> In short: all the difficult stuff is left out ;)
> The goal is not to present a solution that can replace b2 but to have
> a minimal starting point upon which individual library authors or the
> community as a whole can make iterative improvements. If and when BCM
> (or an alternative) is accepted into boost, individual libraries can
> then easily switch to this full-fledged solution and of course any
> author can create a more complete CMake solution for his library at
> any time (as some already have).

In my experience, we want to have both an integration and standalone
CMake file. This split is necessary to avoid problems with multiple
instances of enable_testing() when using one library from another.

   * The integration file builds only what is necessary for integration
     into other projects. This is similar to what you are proposing.

   * The standalone file builds everything including test and
     documentation. This reuses the integration file to build the library
     itself.

If we place your proposed CMake file in the library root, and dependent
libraries start using that location, then it becomes difficult to later
have the standalone CMake file in the library root, which is the more
natural choice. So we should be cautious about where we place these
files.

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

[cmake] Pull request announcement

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Bjorn Reese via Boost
> Sent: Saturday, September 15, 2018 2:11 PM
> To: Mike Dev via Boost <[hidden email]>
> Cc: Bjorn Reese <[hidden email]>
> Subject: Re: [boost] [cmake] Pull request announcement
>
> On 09/14/18 13:44, Mike Dev via Boost wrote:
>
> > This will not address
> > - Testing
> [...]
> > In short: all the difficult stuff is left out ;)
> > The goal is not to present a solution that can replace b2 but to have
> > a minimal starting point upon which individual library authors or the
> > community as a whole can make iterative improvements. If and when BCM
> > (or an alternative) is accepted into boost, individual libraries can
> > then easily switch to this full-fledged solution and of course any
> > author can create a more complete CMake solution for his library at
> > any time (as some already have).
>
> In my experience, we want to have both an integration and standalone
> CMake file. This split is necessary to avoid problems with multiple
> instances of enable_testing() when using one library from another.
>
>    * The integration file builds only what is necessary for integration
>      into other projects. This is similar to what you are proposing.
>
>    * The standalone file builds everything including test and
>      documentation. This reuses the integration file to build the library
>      itself.
>
> If we place your proposed CMake file in the library root, and dependent
> libraries start using that location, then it becomes difficult to later
> have the standalone CMake file in the library root, which is the more
> natural choice. So we should be cautious about where we place these
> files.

Could you elaborate, why this would require separate/conflicting
cmake files as opposed to having multiple different targets in a
single file?

More to the point: Anything related to testing should reside in a cmake
file inside the "tests" folder, which is called from the cmake
file at the root, but that is mainly a matter of properly structuring the
cmake code  - just as you usually don't put all your code into a single
header file, even if it might end up in a single translation unit in the end.
The same is true for docs.

In particular: Just because a cmake file is processed doesn't mean any
of the targets it contains have to be build automatically.


If you have genuine concerns however, I'm happy to further discuss
them in detail. I certainly don't want to do anything that will prevent
a future full-fledged cmake version.




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

Re: [cmake] Pull request announcement

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

> Well, personally I think that is backwards: Taking a new dependency should
> be a deliberate act that I manually document in my build file (many boost
> libraries already have far too many internal dependencies). Only then do I
> start to (directly) include headers from that dependency.

That's not really how things work in Boost, for better or worse. And of
course dependences sometimes go down, not up.

> But in the end, each library maintainer is of course free to reject /
> alter / extend the cmake file I'm going to propose.

Sure, but what we're discussing here is the ongoing maintenance of the cmake
file, keeping it up to date.

There's another approach; add to Travis a configuration that uses CMake to
test the library, without running `b2 headers` first. Since the header links
won't be present, a missing dependency will immediately cause an error due
to the library not being in the include path.

The problem here is that libraries often need more dependencies to run the
tests, so it might not be possible to use the whole test suite as-is, but
for libraries where this is an issue, we could add a dedicated
"cmake_test.cpp" that's lighter but does at least test whether the library
compiles at all.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 15 Sep 2018 at 10:11, mike via Boost <[hidden email]> wrote:
>
> I'm pretty sure the desire of the steering committee, many users and probably
> A lot of boost maintainers is that b2 gets completely replaced by a cmake based
> solution someday (e.g. in the form of BCM).

Unless you poll the community the "pretty sureness" has no connection
to the reality.

I am a user and developer quite heavily sold to CMake
I use CMake for Boost development.
I would like to see CMake accepted as officially offered and supported
build configuration.
But, I do not expect CMake to replace Boost.Build.

Despite that I quite often suffer from motion sickness when
I have to write a non-trivial Jamfile script, I consider Boost.Build
an excellent build system and I do rely on Boost.Build for
Boost development developing and testing.

<my-view-at-ideal-world>
I would like to see
- CMake and Boost.Build first class citizen build systems in Boost
- each maintained by dedicated team devoted to one or the other
- non-competing, but complementing

Next, all references to Boost.Build and Jamfiles wiped out from the
library requirements [1].
Instead, the whole community of Boost maintainers and teams of the respectful
build configurations (ie. CMake and Boost.Build) should offer library author(s)
any help required to integrate the libraries into the officially
supported build systems.

Build configurations are there as common layers glueing Boost libraires for
practical convenience in development and usage, and they should be
common collaborative responsibility.
</my-view-at-ideal-world>

FWIW, since substantial concern of library reviews are C++ code and
documentation, only,
lack of Jamfile-s is not a stopper preventing successful acceptance into Boost!

The requirements [1] clearly states the build integration happens
*after* the fact:
"Once a library is accepted as part of the Boost C++ Libraries it is
required that it integrate
properly into the development, testing, documentation, and release processes."

Then, Jamfile 'transitively' required via the testing policy [2]
"A Jamfile to drive the regression tests for the library"

The Boost.Build-related requirements for testing policy were
established in times when no
Travis CI/AppVeyor/CircleC/Azure Pipelines existed, but Boost heavily
relied on in-house
regression tests waterfall. Now, perhaps the requirement can shift the weight
towards the CI services, make the Jamfile optional and participation
in the Boost
regression tests waterfall complementary.

However, an update to the policies and requirements will be necessary
in order to
make CMake (or any other new build system) officially supported.

[1] https://www.boost.org/development/requirements.html
[2] https://www.boost.org/development/test.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
AMDG

On 09/15/2018 12:01 PM, Mateusz Loskot via Boost wrote:
> <snip>
> FWIW, since substantial concern of library reviews are C++ code and
> documentation, only,
> lack of Jamfile-s is not a stopper preventing successful acceptance into Boost!
>
> The requirements [1] clearly states the build integration happens
> *after* the fact:

Right.  In practice, libraries often do not have
Jamfiles when they are reviewed and it usually
only merits a note that they need to be added
before inclusion.

In Christ,
Steven Watanabe

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 14.09.18 13:44, Mike Dev via Boost wrote:

> Dear all,
>
> unless I'm encountering an overwhelming resistance to this idea
> here on the ml, I intend to create a batch of PRs that introduce
> minimal cmake support to a large subset of boost libraries
> (maybe even all).
>
> [snip]
>
>
> Finally, please don't nick-pick this to death.
> I'd like to have a more complete solution too, but it isn't
> coming, so let's do the minimum we can and go on from there.
> Note that the advantage of such a minimal solution is also that
> there are very few design decisions to make that may later turn
> out to be wrong and then create a maintenance burden.
>
> The only things that are visible on an interface level
> (and thus should remain reasonable stable) are:
>
> [snip]
>

I have a working prototype:
https://github.com/raffienficiaud/boost-cmake

Please give a try, it is very easy to use and it is still working.

It is honoring the inter-libraries dependencies.
It has a nice design IMO, and is handling project dependencies in an ok
fashion, with very little overhead. An additional plan was to integrate
the automatic dependency tool discovery in it (made by Peter Dimov).

Quickbook is here (compilation), and I am almost done with exposing
functions to compile the doc of each project.

There is something I was not able to achieve though: detecting the
version of the CRT for Visual. This affects apparently some project
dependencies (regex + libICU).

I would be happy to discuss about this offline, with a set of interested
people. In particular, the design is not intrusive and it lets library
expose their cmake inside boost or independently.

I stopped working on this some time ago because I was lacking time, but
I am interested in resurrecting it, and it is on my todo list.

Best,
Raffi


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/15/18 17:32, mike via Boost wrote:

> Could you elaborate, why this would require separate/conflicting
> cmake files as opposed to having multiple different targets in a
> single file?

If I include your project's root CMake file that contains tests
added by add_test(), then I cannot avoid those when running my own
tests.

> If you have genuine concerns however, I'm happy to further discuss
> them in detail. I certainly don't want to do anything that will prevent
> a future full-fledged cmake version.

Difficult to tell without seening your CMake files.

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Sep 15, 2018 at 11:33 AM mike via Boost <[hidden email]>
wrote:

> > -----Original Message-----
> > From: Boost <[hidden email]> On Behalf Of Bjorn Reese
> via Boost
> > Sent: Saturday, September 15, 2018 2:11 PM
> > To: Mike Dev via Boost <[hidden email]>
> > Cc: Bjorn Reese <[hidden email]>
> > Subject: Re: [boost] [cmake] Pull request announcement
> >
> > On 09/14/18 13:44, Mike Dev via Boost wrote:
> >
> > > This will not address
> > >     - Testing
> > [...]
> > > In short: all the difficult stuff is left out ;)
> > > The goal is not to present a solution that can replace b2 but to have
> > > a minimal starting point upon which individual library authors or the
> > > community as a whole can make iterative improvements. If and when BCM
> > > (or an alternative) is accepted into boost, individual libraries can
> > > then easily switch to this full-fledged solution and of course any
> > > author can create a more complete CMake solution for his library at
> > > any time (as some already have).
> >
> > In my experience, we want to have both an integration and standalone
> > CMake file. This split is necessary to avoid problems with multiple
> > instances of enable_testing() when using one library from another.
> >
> >    * The integration file builds only what is necessary for integration
> >      into other projects. This is similar to what you are proposing.
> >
> >    * The standalone file builds everything including test and
> >      documentation. This reuses the integration file to build the library
> >      itself.
> >
> > If we place your proposed CMake file in the library root, and dependent
> > libraries start using that location, then it becomes difficult to later
> > have the standalone CMake file in the library root, which is the more
> > natural choice. So we should be cautious about where we place these
> > files.
>
> Could you elaborate, why this would require separate/conflicting
> cmake files as opposed to having multiple different targets in a
> single file?
>
> More to the point: Anything related to testing should reside in a cmake
> file inside the "tests" folder, which is called from the cmake
> file at the root, but that is mainly a matter of properly structuring the
> cmake code  - just as you usually don't put all your code into a single
> header file, even if it might end up in a single translation unit in the
> end.
> The same is true for docs.
>
> In particular: Just because a cmake file is processed doesn't mean any
> of the targets it contains have to be build automatically.
>
>
> If you have genuine concerns however, I'm happy to further discuss
> them in detail. I certainly don't want to do anything that will prevent
> a future full-fledged cmake version.
>
>
I have used CMake for about 10 years now on pretty large projects, and I
have
never seen a need to have different CMakeLists files for different purposes.
If you want to provide a build option where tests are not built or
executed,
you would add a top level option (throwing in examples and docs too):

OPTION(BOOST_DOCS "Build documentation." OFF)     # most people won't have
the required tooling
OPTION(BOOST_EXAMPLES "Build examples." ON)
OPTION(BOOST_TESTS "Build the tests." ON)

Unlike b2, tests do not typically run as part of a build when you use
cmake.
There are three phases of a cmake based build (well, four really...)

1. Create an out-of-tree build directory and generate the build environment
with cmake.
2. Build using the generated build environment (which can be invoked with
"cmake --build .")
3. Run tests using ctest.
(4. cpack to build packages)

If you were to perform step 1 (generating the build) with "cmake
-DBOOST_TESTS=OFF"
then step 3 would either do nothing or produce an error indicating tests
were disabled.

Someone asked what the naming convention for the libraries should be.
You can teach CMake how to name libraries; the naming convention can be
identical
to how b2 does it.  I don't see why it has to be any different than b2.

CMake isn't without it's oddities either.  Selecting the build architecture
and type (debug, x64)
is done in step 1 on unix, but it is done on step 2 on windows.  CMake does
not natively provide
windows package management.  In all of the CMake build systems I have used
or created so
far I have always had to make an environmental harness to deal with third
party deps.  If anyone
has tried to build libicu on windows (as an example), you know what a pain
this can be.
Therefore for it to be successful, tight integration with a package manager
that supports Windows
would be ideal - something that can provide libicu and the other boost
dependencies automatically.
I believe for example conan has some cmake integration.

Finally, someone suggested the project maintain both build systems long
term.
That would be a mistake.
I've seen what this can do in other projects (like Apache Thrift, which
uses autoconf for a
complete linux build, and cmake for windows which is only a subset of
languages).
Each check-in would need to prove it builds correctly in two very different
build systems.
It is a lot to ask of folks submitting changes, but obviously the
"complete" build environment
has to work until the new one becomes "complete" and replaces it.

- Jim

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
Could perhaps some of the more experienced developers provide sth like a
pro and con list comparing cmake and the boost.build system?
(maybe also including the coverage of test and documentation?) or also
examples where we can see the benefit in terms of simplicity, maintainence,
user experience :-), etc.

I think some contributors/maintainers (including myself) are not able to
appreciate (lack of experience/knowledge) the advantage of cmake over the
boost.build system. For some the 'real' benefits might not be as clear as
for the experienced users of build systems.

Best
C



Am So., 16. Sep. 2018 um 13:47 Uhr schrieb James E. King III via Boost <
[hidden email]>:

> On Sat, Sep 15, 2018 at 11:33 AM mike via Boost <[hidden email]>
> wrote:
>
> > > -----Original Message-----
> > > From: Boost <[hidden email]> On Behalf Of Bjorn Reese
> > via Boost
> > > Sent: Saturday, September 15, 2018 2:11 PM
> > > To: Mike Dev via Boost <[hidden email]>
> > > Cc: Bjorn Reese <[hidden email]>
> > > Subject: Re: [boost] [cmake] Pull request announcement
> > >
> > > On 09/14/18 13:44, Mike Dev via Boost wrote:
> > >
> > > > This will not address
> > > >     - Testing
> > > [...]
> > > > In short: all the difficult stuff is left out ;)
> > > > The goal is not to present a solution that can replace b2 but to have
> > > > a minimal starting point upon which individual library authors or the
> > > > community as a whole can make iterative improvements. If and when BCM
> > > > (or an alternative) is accepted into boost, individual libraries can
> > > > then easily switch to this full-fledged solution and of course any
> > > > author can create a more complete CMake solution for his library at
> > > > any time (as some already have).
> > >
> > > In my experience, we want to have both an integration and standalone
> > > CMake file. This split is necessary to avoid problems with multiple
> > > instances of enable_testing() when using one library from another.
> > >
> > >    * The integration file builds only what is necessary for integration
> > >      into other projects. This is similar to what you are proposing.
> > >
> > >    * The standalone file builds everything including test and
> > >      documentation. This reuses the integration file to build the
> library
> > >      itself.
> > >
> > > If we place your proposed CMake file in the library root, and dependent
> > > libraries start using that location, then it becomes difficult to later
> > > have the standalone CMake file in the library root, which is the more
> > > natural choice. So we should be cautious about where we place these
> > > files.
> >
> > Could you elaborate, why this would require separate/conflicting
> > cmake files as opposed to having multiple different targets in a
> > single file?
> >
> > More to the point: Anything related to testing should reside in a cmake
> > file inside the "tests" folder, which is called from the cmake
> > file at the root, but that is mainly a matter of properly structuring the
> > cmake code  - just as you usually don't put all your code into a single
> > header file, even if it might end up in a single translation unit in the
> > end.
> > The same is true for docs.
> >
> > In particular: Just because a cmake file is processed doesn't mean any
> > of the targets it contains have to be build automatically.
> >
> >
> > If you have genuine concerns however, I'm happy to further discuss
> > them in detail. I certainly don't want to do anything that will prevent
> > a future full-fledged cmake version.
> >
> >
> I have used CMake for about 10 years now on pretty large projects, and I
> have
> never seen a need to have different CMakeLists files for different
> purposes.
> If you want to provide a build option where tests are not built or
> executed,
> you would add a top level option (throwing in examples and docs too):
>
> OPTION(BOOST_DOCS "Build documentation." OFF)     # most people won't have
> the required tooling
> OPTION(BOOST_EXAMPLES "Build examples." ON)
> OPTION(BOOST_TESTS "Build the tests." ON)
>
> Unlike b2, tests do not typically run as part of a build when you use
> cmake.
> There are three phases of a cmake based build (well, four really...)
>
> 1. Create an out-of-tree build directory and generate the build environment
> with cmake.
> 2. Build using the generated build environment (which can be invoked with
> "cmake --build .")
> 3. Run tests using ctest.
> (4. cpack to build packages)
>
> If you were to perform step 1 (generating the build) with "cmake
> -DBOOST_TESTS=OFF"
> then step 3 would either do nothing or produce an error indicating tests
> were disabled.
>
> Someone asked what the naming convention for the libraries should be.
> You can teach CMake how to name libraries; the naming convention can be
> identical
> to how b2 does it.  I don't see why it has to be any different than b2.
>
> CMake isn't without it's oddities either.  Selecting the build architecture
> and type (debug, x64)
> is done in step 1 on unix, but it is done on step 2 on windows.  CMake does
> not natively provide
> windows package management.  In all of the CMake build systems I have used
> or created so
> far I have always had to make an environmental harness to deal with third
> party deps.  If anyone
> has tried to build libicu on windows (as an example), you know what a pain
> this can be.
> Therefore for it to be successful, tight integration with a package manager
> that supports Windows
> would be ideal - something that can provide libicu and the other boost
> dependencies automatically.
> I believe for example conan has some cmake integration.
>
> Finally, someone suggested the project maintain both build systems long
> term.
> That would be a mistake.
> I've seen what this can do in other projects (like Apache Thrift, which
> uses autoconf for a
> complete linux build, and cmake for windows which is only a subset of
> languages).
> Each check-in would need to prove it builds correctly in two very different
> build systems.
> It is a lot to ask of folks submitting changes, but obviously the
> "complete" build environment
> has to work until the new one becomes "complete" and replaces it.
>
> - Jim
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 16 Sep 2018 at 14:47, James E. King III via Boost <
[hidden email]> wrote:

> Therefore for it to be successful, tight integration with a package manager
> that supports Windows
> would be ideal - something that can provide libicu and the other boost
> dependencies automatically.
>

I'm not generalising the "other boost dependencies" (I would say MPIR (a
GMP-drop-in) is deficient), but vcpkg <https://github.com/Microsoft/vcpkg>
provides ICU (cross platform, win, nix, osx). It uses CMake and actually
builds Boost (with ICU support) as well.

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Sep 16, 2018 at 6:47 AM James E. King III via Boost <
[hidden email]> wrote:

> Unlike b2, tests do not typically run as part of a build when you use
> cmake.
>

B2, as typically used, does *not* typically run tests as part of the build.
You have to explicitly build the test project (or targets). And if you are
not doing the typical thing of putting tests in a separate project you can
type two words (plus a semi-colon) to avoid automatically building *any*
one target.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 16 Sep 2018, 14:21 Cem Bassoy via Boost, <[hidden email]>
wrote:

> Could perhaps some of the more experienced developers provide sth like a
> pro and con list comparing cmake and the boost.build system?
>

IMHO, those have been listed here in countless posts already.
One 'just' needs to dedicate one or two hours of life and learn about it
from the archive.

Instead of reposting pros/cons here again to make it into yet another
forgotten post,
those who care and need it should create a table on wiki with clear
structured comparison.

However, we should stop arguing CMake vs Build.Boost immediately, unless we
have too much time to kill.
Instead, we should work out how (not if!) to make room for both camps,
Boost.Build and CMake, to co-exist officially and in peace within Boost.

Best regards,
Mateusz Loskot

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