Re: [release] 1.69.0 deadline for new libraries approaching

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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
Marshall Clow wrote:

> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes

OK... do we want CMake config files installed by 1.69 or not, then?

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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list


On 22/10/2018 18:19, Peter Dimov via Boost wrote:
> Marshall Clow wrote:
>
>> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
>
> OK... do we want CMake config files installed by 1.69 or not, then?

I assume as pure additions they're not really breaking changes?

In any case it's going to be a pain to avoid merging those specific
files to master over multiple repros.

Best, John.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
> Marshall Clow wrote:
>
>> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
>
> OK... do we want CMake config files installed by 1.69 or not, then?

I'd like to know this as well.  If so, I presume that we can consider
the Boost/CMake issues resolved and we can just move on from 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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 2018-10-22 02:39 PM, Robert Ramey via Boost wrote:

> On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
>> Marshall Clow wrote:
>>
>>> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
>>
>> OK... do we want CMake config files installed by 1.69 or not, then?
>
> I'd like to know this as well.  If so, I presume that we can consider
> the Boost/CMake issues resolved and we can just move on from this?

What issues do you think are resolved ? As far as I understand, the
current endeavor is to auto-generate config files to make it easier to
consume (individual) Boost libraries in CMake projects. That's entirely
orthogonal to the question of whether and how Boost libraries switch to
CMake.
So, as far as I'm concerned, your effort to agree on a Request For
Proposals is still very much relevant.


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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/22/18 11:45 AM, Stefan Seefeld via Boost wrote:

>>> OK... do we want CMake config files installed by 1.69 or not, then?
>>
>> I'd like to know this as well.  If so, I presume that we can consider
>> the Boost/CMake issues resolved and we can just move on from this?
>
> What issues do you think are resolved ? As far as I understand, the
> current endeavor is to auto-generate config files to make it easier to
> consume (individual) Boost libraries in CMake projects. That's entirely
> orthogonal to the question of whether and how Boost libraries switch to
> CMake.

> So, as far as I'm concerned, your effort to agree on a Request For
> Proposals is still very much relevant.

The reason I ask is that working to implement something presumes that
there's consensus on what should be implemented.  I don't want to find
myself in the position of committing serious effort to a task which has
been eclipsed by events.

Historically, Boost Tooling has been developed in just this way.
Someone with access just implements something and drops on the rest of
us.  I think that this practice is one of the reasons that we've been
frustrated with boost tooling in general.  My proposal is/was an attempt
to break this cycle by approaching from a different angle - inspired by
Boosts success in other aspects - motivating the creating of quality C++
libraries.

Robert Ramey


>
>
> Stefan
>
> --
>
>        ...ich hab' noch einen Koffer in Berlin...
>
>
> _______________________________________________
> 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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 2018-10-22 03:08 PM, Robert Ramey via Boost wrote:

> On 10/22/18 11:45 AM, Stefan Seefeld via Boost wrote:
>
>>>> OK... do we want CMake config files installed by 1.69 or not, then?
>>>
>>> I'd like to know this as well.  If so, I presume that we can
>>> consider the Boost/CMake issues resolved and we can just move on
>>> from this?
>>
>> What issues do you think are resolved ? As far as I understand, the
>> current endeavor is to auto-generate config files to make it easier
>> to consume (individual) Boost libraries in CMake projects. That's
>> entirely orthogonal to the question of whether and how Boost
>> libraries switch to CMake.
>
>> So, as far as I'm concerned, your effort to agree on a Request For
>> Proposals is still very much relevant.
>
> The reason I ask is that working to implement something presumes that
> there's consensus on what should be implemented.  I don't want to find
> myself in the position of committing serious effort to a task which
> has been eclipsed by events.
>
> Historically, Boost Tooling has been developed in just this way.
> Someone with access just implements something and drops on the rest of
> us.  I think that this practice is one of the reasons that we've been
> frustrated with boost tooling in general.

I understand, and agree. In fact, my main argument against the
"wholesale move to CMake" is precisely that we (the maintainers) are
left to deal with users who will expect support when something doesn't
quite work the way *they* expect. So even if the initial infrastructure
generation is done by someone else (or is automated entirely), this
still has an impact on the projects' maintenance.

In that sense I think the inclusion of those config files, or at least,
any "official support" that may come with it (implied or not), is
something that needs to be agreed upon. And *that* would definitely be
part of your RFP.



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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/22/18 12:25 PM, Stefan Seefeld via Boost wrote:
> On 2018-10-22 03:08 PM, Robert Ramey via Boost wrote:

> In that sense I think the inclusion of those config files, or at least,
> any "official support" that may come with it (implied or not), is
> something that needs to be agreed upon. And *that* would definitely be
> part of your RFP.

The Draft RFP has received only modest criticism.  Some minor issues
with wording and reservations about the proposal for anonymity of
submitters.  I'm highly doubtful that this is due to universal agreement
that this is path we want go down.  I'm concerned that this is a sign of
lack of interest.  I don't want to embark upon this unless its pretty
strong support from the boost community.  If there's isn't sufficient
support of such an effort now, wwe can always wait another year.

Robert Ramey



>
>
>
> Stefan
>
> --
>
>        ...ich hab' noch einen Koffer in Berlin...
>
>
> _______________________________________________
> 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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Robert Ramey wrote:
> On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
> > Marshall Clow wrote:
> >
> >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
> >
> > OK... do we want CMake config files installed by 1.69 or not, then?
>
> I'd like to know this as well.  If so, I presume that we can consider the
> Boost/CMake issues resolved and we can just move on from this?

I doubt it. The CMake issue is much bigger than this.


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Robert Ramey wrote:
> > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
> > > Marshall Clow wrote:
> > >
> > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
> > >
> > > OK... do we want CMake config files installed by 1.69 or not, then?
> >
> > I'd like to know this as well.  If so, I presume that we can consider
> > the Boost/CMake issues resolved and we can just move on from this?
>
> I doubt it. The CMake issue is much bigger than this.

To expand on that:

The Boost/CMake issues concern four scenarios:

1. CMake users who want to use a pre-built Boost from CMake, after
installing it either with `b2 install`, as usual, or via some other
mechanism;

2. CMake users who want to use Boost (or an individual Boost library) from
CMake without building it with b2 and installing it, but as a subproject,
built by CMake;

3. Building and installing Boost with CMake, replacing the current
Boost.Build building/installing infrastructure;

4. Testing Boost with CMake, replacing the current Boost.Build testing
infrastructure.

Installing CMake config files as part of `b2 install` falls into scenario
number 1. Boost is still built with Boost.Build as always, it's just that in
addition to libboost_foo.a, the user also gets libboost_foo.cmake, which
allows him to do `find_package(boost_foo)` from his CMakeLists.txt file.
Nothing more than that. This doesn't affect, doesn't target, and doesn't
address, scenarios 2-4 at all.


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/22/2018 7:55 PM, Peter Dimov via Boost wrote:

>> Robert Ramey wrote:
>> > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
>> > > Marshall Clow wrote:
>> > >
>> > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
>> > >
>> > > OK... do we want CMake config files installed by 1.69 or not, then?
>> >
>> > I'd like to know this as well.  If so, I presume that we can
>> consider > the Boost/CMake issues resolved and we can just move on
>> from this?
>>
>> I doubt it. The CMake issue is much bigger than this.
>
> To expand on that:
>
> The Boost/CMake issues concern four scenarios:
>
> 1. CMake users who want to use a pre-built Boost from CMake, after
> installing it either with `b2 install`, as usual, or via some other
> mechanism;
>
> 2. CMake users who want to use Boost (or an individual Boost library)
> from CMake without building it with b2 and installing it, but as a
> subproject, built by CMake;
>
> 3. Building and installing Boost with CMake, replacing the current
> Boost.Build building/installing infrastructure;
>
> 4. Testing Boost with CMake, replacing the current Boost.Build testing
> infrastructure.

5. Building a library's documentation with CMake. Quite a number of
libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
with built-in support by Boost Build for this with a jamfile.

>
> Installing CMake config files as part of `b2 install` falls into
> scenario number 1. Boost is still built with Boost.Build as always, it's
> just that in addition to libboost_foo.a, the user also gets
> libboost_foo.cmake, which allows him to do `find_package(boost_foo)`
> from his CMakeLists.txt file. Nothing more than that. This doesn't
> affect, doesn't target, and doesn't address, scenarios 2-4 at all.


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
> 5. Building a library's documentation with CMake. Quite a number of
> libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
> with built-in support by Boost Build for this with a jamfile.

Maybe - but personally I just build my docs pdf and html with a simple
shell script - it's about 5 lines long - easy as pie.

Robert Ramey



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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
> On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
>> 5. Building a library's documentation with CMake. Quite a number of
>> libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
>> with built-in support by Boost Build for this with a jamfile.
>
> Maybe - but personally I just build my docs pdf and html with a simple
> shell script - it's about 5 lines long - easy as pie.

1) Shell scripts are different for Windows, Linux, and Mac OSs.
2) Please provide your "simple" shell script for any OS, much less all
of them, that encapsulates the quickbook -> boostbook -> html/pdf
process in jam files.

Try to understand that even if you do not use the quickbook -> boostbook
-> html/pdf build process a great number of libraries do use it, for
good reason, and those libraries are not going to re-invent the wheel
just because you have an alternate method for creating documentation.

>
> Robert Ramey


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/22/18 9:46 PM, Edward Diener via Boost wrote:

> On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
>> On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
>>> 5. Building a library's documentation with CMake. Quite a number of
>>> libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
>>> with built-in support by Boost Build for this with a jamfile.
>>
>> Maybe - but personally I just build my docs pdf and html with a simple
>> shell script - it's about 5 lines long - easy as pie.
>
> 1) Shell scripts are different for Windows, Linux, and Mac OSs.
> 2) Please provide your "simple" shell script for any OS, much less all
> of them, that encapsulates the quickbook -> boostbook -> html/pdf
> process in jam files.
>
> Try to understand that even if you do not use the quickbook -> boostbook
> -> html/pdf build process a great number of libraries do use it, for
> good reason, and those libraries are not going to re-invent the wheel
> just because you have an alternate method for creating documentation.

Here is the the script I use to build html documentation for the safe
numerics library:

if test x = x$BOOST_ROOT
then
     echo BOOST_ROOT not set
     exit 1
fi
xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc
--nonet db2html.xsl -
cp pre-boost.jpg ../html
cp pre-boost.jpg ../html/eliminate_runtime_penalty
cp pre-boost.jpg ../html/promotion_policies
cp pre-boost.jpg ../html/tutorial
cp StepperMotor.gif ../html/
cp stepper_profile.png ../html/
cp $BOOST_ROOT/doc/src/boostbook.css ../html
cp -R $BOOST_ROOT/doc/html/images ../html

If you want to use it feel free.

Note that it transforms boostbook => html.  How your boostbook file(s)
are created is not addressed here. if you want to include quickbook in
the pipeline or use something like it windows, You'll just have to alter
the script to taste.  Sorry I can't do this for you.

Note that it's actual function is to cut B2 out of the mix. This makes
things much, much simpler.

BTW there are other versions to produce pdf and ebook from the boostbook
files.


>
>>
>> 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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
AMDG

On 10/23/2018 08:54 AM, Robert Ramey via Boost wrote:

> On 10/22/18 9:46 PM, Edward Diener via Boost wrote:
>> On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
>>> On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
>>>> 5. Building a library's documentation with CMake. Quite a number of
>>>> libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
>>>> with built-in support by Boost Build for this with a jamfile.
>>>
>>> Maybe - but personally I just build my docs pdf and html with a
>>> simple shell script - it's about 5 lines long - easy as pie.
>>
>> 1) Shell scripts are different for Windows, Linux, and Mac OSs.
>> 2) Please provide your "simple" shell script for any OS, much less all
>> of them, that encapsulates the quickbook -> boostbook -> html/pdf
>> process in jam files.
>>
>> Try to understand that even if you do not use the quickbook ->
>> boostbook -> html/pdf build process a great number of libraries do use
>> it, for good reason, and those libraries are not going to re-invent
>> the wheel just because you have an alternate method for creating
>> documentation.
>
> Here is the the script I use to build html documentation for the safe
> numerics library:
>
> if test x = x$BOOST_ROOT
> then
>     echo BOOST_ROOT not set
>     exit 1
> fi
> xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc
> --nonet db2html.xsl -

You need a catalog file for --nonet to work.  This script
is not self-contained, because it assumes that the
catalogs for boostbook and docbook are present in the
environment.

> cp pre-boost.jpg ../html
> cp pre-boost.jpg ../html/eliminate_runtime_penalty
> cp pre-boost.jpg ../html/promotion_policies
> cp pre-boost.jpg ../html/tutorial
> cp StepperMotor.gif ../html/
> cp stepper_profile.png ../html/
> cp $BOOST_ROOT/doc/src/boostbook.css ../html
> cp -R $BOOST_ROOT/doc/html/images ../html
>
> If you want to use it feel free.
>
> Note that it transforms boostbook => html.  How your boostbook file(s)
> are created is not addressed here. if you want to include quickbook in
> the pipeline or use something like it windows, You'll just have to alter
> the script to taste.  Sorry I can't do this for you.
>

And that's the real issue.  Scripts like this are
work great as long as you're only running them in
a specific environment.  If you try to make them
portable, they'll quickly become at least as complex
as the b2 implementation.

> Note that it's actual function is to cut B2 out of the mix. This makes
> things much, much simpler.
>
> BTW there are other versions to produce pdf and ebook from the boostbook
> files.
>

In Christ,
Steven Watanabe

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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
On 10/23/18 8:16 AM, Steven Watanabe via Boost wrote:

> You need a catalog file for --nonet to work.  This script
> is not self-contained, because it assumes that the
> catalogs for boostbook and docbook are present in the
> environment.

Right - I added these when I discovered that the damn thing was going
out on the net every time I built something.

> And that's the real issue.  Scripts like this are
> work great as long as you're only running them in
> a specific environment.  If you try to make them
> portable, they'll quickly become at least as complex
> as the b2 implementation.

Right - that's why I didn't try to make it really portable.  I made it
simple enough to work and simple enough to adjust to taste. B2 places a
impenetrable layer between me building the documentation.  My script is
100 times easier to work with than the b2 implementation.
>> Note that it's actual function is to cut B2 out of the mix. This makes
>> things much, much simpler.

>> BTW there are other versions to produce pdf and ebook from the boostbook
>> files.
>>

Robert Ramey

>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> 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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
Robert Ramey wrote:

> Right - that's why I didn't try to make it really portable.

That's fine but the Boost documentation build doesn't run on your machine,
so it won't be able to use your script then.


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2018-10-23 12:14 PM, Robert Ramey via Boost wrote:

[...]

> Right - that's why I didn't try to make it really portable.

Can we please simply agree that a build system for Boost needs to
provide a portable way to build the docs, and then stop this off-topic
discussion ?


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: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Robert Ramey via Boost
> Sent: 23 October 2018 15:54
> To: [hidden email]
> Cc: Robert Ramey
> Subject: Re: [boost] [release] 1.69.0 deadline for new libraries approaching
>
> On 10/22/18 9:46 PM, Edward Diener via Boost wrote:
> > On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
> >> On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
> >>> 5. Building a library's documentation with CMake. Quite a number of
> >>> libraries currently use the Quickbook -> Boostbook -> html/pdf cycle
> >>> with built-in support by Boost Build for this with a jamfile.
> >>
> >> Maybe - but personally I just build my docs pdf and html with a simple
> >> shell script - it's about 5 lines long - easy as pie.
> >
> > 1) Shell scripts are different for Windows, Linux, and Mac OSs.
> > 2) Please provide your "simple" shell script for any OS, much less all
> > of them, that encapsulates the quickbook -> boostbook -> html/pdf
> > process in jam files.
> >
> > Try to understand that even if you do not use the quickbook -> boostbook
> > -> html/pdf build process a great number of libraries do use it, for
> > good reason, and those libraries are not going to re-invent the wheel
> > just because you have an alternate method for creating documentation.
>
> Here is the the script I use to build html documentation for the safe
> numerics library:
>
> if test x = x$BOOST_ROOT
> then
>      echo BOOST_ROOT not set
>      exit 1
> fi
> xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc
> --nonet db2html.xsl -
> cp pre-boost.jpg ../html
> cp pre-boost.jpg ../html/eliminate_runtime_penalty
> cp pre-boost.jpg ../html/promotion_policies
> cp pre-boost.jpg ../html/tutorial
> cp StepperMotor.gif ../html/
> cp stepper_profile.png ../html/
> cp $BOOST_ROOT/doc/src/boostbook.css ../html
> cp -R $BOOST_ROOT/doc/html/images ../html
>
> If you want to use it feel free.
>
> Note that it transforms boostbook => html.  How your boostbook file(s)
> are created is not addressed here. if you want to include quickbook in
> the pipeline or use something like it windows, You'll just have to alter
> the script to taste.  Sorry I can't do this for you.
>
> Note that it's actual function is to cut B2 out of the mix. This makes
> things much, much simpler.

My script to build math docs is

> b2

or >b2 pdf

;-)

Paul

PS But thanks for all those who did the work that went into the jamfile :-)



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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 23.10.18 18:19, Stefan Seefeld via Boost wrote:

> On 2018-10-23 12:14 PM, Robert Ramey via Boost wrote:
>
> [...]
>
>> Right - that's why I didn't try to make it really portable.
>
> Can we please simply agree that a build system for Boost needs to
> provide a portable way to build the docs, and then stop this off-topic
> discussion ?
>

Like this?

https://github.com/raffienficiaud/boost-cmake/blob/master/boost/libs/test/doc/CMakeLists.txt#L26

and this?

https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quickbook.cmake

Does not work well with Doxygen though.


Raffi


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

Re: [release] 1.69.0 deadline for new libraries approaching

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/23/18 9:17 AM, Peter Dimov via Boost wrote:
> Robert Ramey wrote:
>
>> Right - that's why I didn't try to make it really portable.
>
> That's fine but the Boost documentation build doesn't run on your
> machine, so it won't be able to use your script then.

LOL - the b2 based one doesn't run on my machine either.  It's easier
and faster to craft the script than to get b2 to do it.  And I place the
html and pdf versions into the repo so users don't have to build it.

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



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