I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible. Are there any known showstoppers? If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted. Library authors who use Boostbook/Quickbook, but don't have time to look at the full snapshot, might want to check http://boost.cowic.de/rc/boost-docs.7z Known problems/questions: * index.html ??? needs to be replaced by new library count. * pdf docs: Do we want to do anything more for this release? Thanks, --Beman
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
I probably should mention the improved build procedure in the release notes page. Daniel, I guess if I hide his under "Updated tools->Build" nobody will read it. Maybe I should add "Improved build process" section somewhere after "Updated libraries"? - Volodya
2009/4/22 Vladimir Prus <vladimir@codesourcery.com>:
Daniel, I guess if I hide his under "Updated tools->Build" nobody will read it. Maybe I should add "Improved build process" section somewhere after "Updated libraries"?
Do what you think best, there isn't a fixed policy. If I object to anything I'll say so. I only added the 'Updated tools' section because I had a lot of changes for boostbook and quickbook. It probably needs a bit of editing since important changes are mixed up with minor ones. If you want to draw attention to certain changes, we could add an introduction to highlight them. The significant changes seem to be: signals2, your build changes and pdf support in boostbook. Daniel
Daniel James wrote:
2009/4/22 Vladimir Prus <vladimir@codesourcery.com>:
Daniel, I guess if I hide his under "Updated tools->Build" nobody will read it. Maybe I should add "Improved build process" section somewhere after "Updated libraries"?
Do what you think best, there isn't a fixed policy. If I object to anything I'll say so. I only added the 'Updated tools' section because I had a lot of changes for boostbook and quickbook. It probably needs a bit of editing since important changes are mixed up with minor ones.
If you want to draw attention to certain changes, we could add an introduction to highlight them. The significant changes seem to be: signals2, your build changes and pdf support in boostbook.
Ok, let me see if I can get right effect with just sections. - Volodya
On Wed, Apr 22, 2009 at 8:55 AM, Beman Dawes <bdawes@acm.org> wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
What time tomorrow :) I've bee side-tracked also. There may be a couple of outstanding changes in the BGL that need to be merged into the release branch. I can verify these tonight. Andrew Sutton andrew.n.sutton@gmail.com
On Wed, Apr 22, 2009 at 10:37 AM, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:
On Wed, Apr 22, 2009 at 8:55 AM, Beman Dawes <bdawes@acm.org> wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
What time tomorrow :) I've bee side-tracked also. There may be a couple of outstanding changes in the BGL that need to be merged into the release branch. I can verify these tonight.
It will be later rather than earlier. Probably not until tomorrow (Thursday) evening, US east coast time. But please merge ASAP so tests can cycle. --Beman
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted.
Seems like bootstrap.bat is busted: C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22>.\bootstrap.bat C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># Copyright (C) 2009 Vladimir Prus '#' is not recognized as an internal or external command, operable program or batch file. C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># '#' is not recognized as an internal or external command, operable program or batch file. C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># Distributed under the Boost Software License , Version 1.0. '#' is not recognized as an internal or external command, operable program or batch file. C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># (See accompanying file LICENSE_1_0.txt or ht tp://www.boost.org/LICENSE_1_0.txt) '#' is not recognized as an internal or external command, operable program or batch file. Building Boost.Jam build engine The system cannot find the file specified. If you want to put a comment in a DOS batch file, you use REM, not #. I'm a bit dismayed that this apparently got merged to release without even being tested. I notice that later this script instructs the user to type "./bjam --help". Remember, this is a windows batch script. The command should be ".\bjam --help" (note the forward slash). Under cygwin, ./bootstrap.sh seems to build bjam successfully. The user is then instructed to type ./bjam --help to get command line help. This outputs: Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17 ... and then bjam just hangs and pegs the CPU! Can somebody else corroborate? I gave up testing after this except to click around in the docs. They look ok.
Library authors who use Boostbook/Quickbook, but don't have time to look at the full snapshot, might want to check http://boost.cowic.de/rc/boost-docs.7z
Image links are broken in this docs-only archive (e.g. the link to boost.png and the links to the navigation icons). It probably doesn't matter though because the docs in the full archive are fine. -- Eric Niebler BoostPro Computing http://www.boostpro.com
2009/4/23 Eric Niebler <eric@boostpro.com>:
Image links are broken in this docs-only archive (e.g. the link to boost.png and the links to the navigation icons). It probably doesn't matter though because the docs in the full archive are fine.
It isn't really meant for general use, it just cotains 'doc/html' so that the release scripts can copy it into place. So any images that aren't under that directory will be missing. Links will also be broken. If anyone wants to use it for testing, they could copy it to the appropriate location in a local checkout of release. Daniel
Eric Niebler wrote:
Under cygwin, ./bootstrap.sh seems to build bjam successfully.
When I try it in cygwin in ~/boost/, two errors are printed to the console before the "detecting Python, Unicode for regex, making Boost.Build config, etc" text: $ ./bootstrap.sh Building Boost.Jam with toolset gcc... ./bootstrap.sh: line 219: cd: /home/Jeffrey: No such file or directory ./bootstrap.sh: line 220: cd: ./tools/jam/src: No such file or directory tools/jam/src//bjam cp: cannot stat `./tools/jam/src//bjam': No such file or directory This is probably because my Windows username, and thus my cygwin home directory, contains a space (it's "Jeffrey Bosboom"), and the argument to cd wasn't properly escaped. I couldn't run ./bjam --help at that point, as it didn't get copied. I re-extracted the 7z-ball to /tmp/boost/ and bootstrap.sh ran without error.
The user is then instructed to type ./bjam --help to get command line help. This outputs:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs and pegs the CPU! Can somebody else corroborate?
./bjam --help runs fine for me. You might want to try rebasing the Cygwin DLLs, which seems to be the magic fix for weird problems like this. (Close all Cygwin processes, run /bin/ash.exe (from the Windows graphical shell or Start --> Run...), /bin/rebaseall .) Apparently the Cygwin dynamic loader is broken; I had to do this to run perl.exe a while ago and hence I don't encounter the problem when running bjam. This is just speculation, though. Building seems to go okay. It does print "Building C++ Boost" at the beginning, which is a bit confusing (there are no other Boosts, are there?), and the warnings about missing optional features should say "if you don't need this feature, you can safely ignore this warning" rather than just "this is optional". I don't have the cycles to spare to build it all right now, but if you want me to try one particular target or such, let me know. --Jeffrey Bosboom
jbosboom@uci.edu wrote:
Eric Niebler wrote:
Under cygwin, ./bootstrap.sh seems to build bjam successfully.
When I try it in cygwin in ~/boost/, two errors are printed to the console before the "detecting Python, Unicode for regex, making Boost.Build config, etc" text:
$ ./bootstrap.sh Building Boost.Jam with toolset gcc... ./bootstrap.sh: line 219: cd: /home/Jeffrey: No such file or directory ./bootstrap.sh: line 220: cd: ./tools/jam/src: No such file or directory tools/jam/src//bjam cp: cannot stat `./tools/jam/src//bjam': No such file or directory
Thanks for report, I've added necessary quoting.
This is probably because my Windows username, and thus my cygwin home directory, contains a space (it's "Jeffrey Bosboom"), and the argument to cd wasn't properly escaped. I couldn't run ./bjam --help at that point, as it didn't get copied. I re-extracted the 7z-ball to /tmp/boost/ and bootstrap.sh ran without error.
The user is then instructed to type ./bjam --help to get command line help. This outputs:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs and pegs the CPU! Can somebody else corroborate?
./bjam --help runs fine for me. You might want to try rebasing the Cygwin DLLs, which seems to be the magic fix for weird problems like this. (Close all Cygwin processes, run /bin/ash.exe (from the Windows graphical shell or Start --> Run...), /bin/rebaseall .) Apparently the Cygwin dynamic loader is broken; I had to do this to run perl.exe a while ago and hence I don't encounter the problem when running bjam. This is just speculation, though.
Building seems to go okay. It does print "Building C++ Boost" at the beginning, which is a bit confusing (there are no other Boosts, are there?),
Well, it meant to just say what is being built. In fact, it should be: Building the Boost C++ Libraries to match official name of the project -- would that be less confusing.
and the warnings about missing optional features should say "if you don't need this feature, you can safely ignore this warning" rather than just "this is optional".
I probably can fix this -- though it's per-library change and therefore something annoying.
I don't have the cycles to spare to build it all right now, but if you want me to try one particular target or such, let me know.
Thanks for your testing! - Volodya
Eric Niebler wrote:
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted.
Seems like bootstrap.bat is busted:
C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22>.\bootstrap.bat
C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># Copyright (C) 2009 Vladimir Prus '#' is not recognized as an internal or external command, operable program or batch file.
Boo! Copyright addition was the last change to that file, and I have failed to test it. Fixed now.
C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># '#' is not recognized as an internal or external command, operable program or batch file.
C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># Distributed under the Boost Software License , Version 1.0. '#' is not recognized as an internal or external command, operable program or batch file.
C:\boost\org\1.39-alpha-full\boost-windows-2009-04-22># (See accompanying file LICENSE_1_0.txt or ht tp://www.boost.org/LICENSE_1_0.txt) '#' is not recognized as an internal or external command, operable program or batch file. Building Boost.Jam build engine The system cannot find the file specified.
If you want to put a comment in a DOS batch file, you use REM, not #. I'm a bit dismayed that this apparently got merged to release without even being tested.
I notice that later this script instructs the user to type "./bjam --help". Remember, this is a windows batch script. The command should be ".\bjam --help" (note the forward slash).
Fixed. Note that the command that user is instructed to actually run uses right slashes. - Volodya
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
Many of the HTML doc files have <script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline. Can the docs be re-generated before release without these scripts? Thanks, -Steve [1] http://labnol.blogspot.com/2005/11/prevent-google-analytics-from-tracking.ht... [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524186
On Thu, Apr 23, 2009 at 11:49:13PM -0500, Steve M. Robbins wrote:
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
Many of the HTML doc files have
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline.
Can the docs be re-generated before release without these scripts?
Forgot to list the offending files: libs/gil/doc (basically all of them) tools/build/v2/index.html (this is true of both release and trunk) Thanks, -Steve
Steve M. Robbins wrote:
On Thu, Apr 23, 2009 at 11:49:13PM -0500, Steve M. Robbins wrote:
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
Many of the HTML doc files have
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline.
Can the docs be re-generated before release without these scripts?
Forgot to list the offending files:
libs/gil/doc (basically all of them) tools/build/v2/index.html
(this is true of both release and trunk)
I am unsure that privacy concerns there are might be. I don't think Google provides per-IP data at all, and even if they did, it's unclear why the list of documentation pages read counts as minimally sensitive information. - Volodya
On Fri, Apr 24, 2009 at 10:55:42AM +0400, Vladimir Prus wrote:
Steve M. Robbins wrote:
On Thu, Apr 23, 2009 at 11:49:13PM -0500, Steve M. Robbins wrote:
Beman Dawes wrote:
I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible.
Are there any known showstoppers?
Many of the HTML doc files have
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline.
Can the docs be re-generated before release without these scripts?
Forgot to list the offending files:
libs/gil/doc (basically all of them) tools/build/v2/index.html
(this is true of both release and trunk)
I am unsure that privacy concerns there are might be. I don't think Google provides per-IP data at all, and even if they did, it's unclear why the list of documentation pages read counts as minimally sensitive information.
Certainly many people will not be bothered by this, but some will: I posted because I was asked to remove the script from Debian [1]. A compromise is possible: remove the tracking from the source files, used in offline reading, but add it for docs located on the web site, as tools/build/v2/roll.sh appears to do. Regards, -Steve [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524186
On Sat, Apr 25, 2009 at 6:36 PM, Steve M. Robbins <steve@sumost.ca> wrote:
On Fri, Apr 24, 2009 at 10:55:42AM +0400, Vladimir Prus wrote:
Steve M. Robbins wrote:
On Thu, Apr 23, 2009 at 11:49:13PM -0500, Steve M. Robbins wrote:
Beman Dawes wrote: > I've gotten badly sidetracked by non-Boost work, but would like to get > the 1.39.0 beta out tomorrow if at all possible. > > Are there any known showstoppers?
Many of the HTML doc files have
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline.
Can the docs be re-generated before release without these scripts?
Forgot to list the offending files:
libs/gil/doc (basically all of them) tools/build/v2/index.html
(this is true of both release and trunk)
I am unsure that privacy concerns there are might be. I don't think Google provides per-IP data at all, and even if they did, it's unclear why the list of documentation pages read counts as minimally sensitive information.
Certainly many people will not be bothered by this, but some will: I posted because I was asked to remove the script from Debian [1].
A compromise is possible: remove the tracking from the source files, used in offline reading, but add it for docs located on the web site, as tools/build/v2/roll.sh appears to do.
It seems to me that it is a normal practice for a web site to track usage of page visits and visitors. But I'm quite uncomfortable with offline tracking. Thus I like your suggestion that a distinction be made between the distribution package and the web site. --Beman
On Sun, Apr 26, 2009 at 1:03 PM, Beman Dawes <bdawes@acm.org> wrote:
It seems to me that it is a normal practice for a web site to track usage of page visits and visitors. But I'm quite uncomfortable with offline tracking. Thus I like your suggestion that a distinction be made between the distribution package and the web site.
I agree, it has no place offline. It could actually help if some stats from the online tracking were published to this list though. Docs with high traffic (relative to other docs from the same lib) might help indicate people are having a hard time remembering how to use some code, and could use better explaining (or better code) so they remember the first time. -- Cory Nelson
----- Original Message ----- From: "Cory Nelson" <phrosty@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, April 26, 2009 10:31 PM Subject: Re: [boost] google-analytics and privacy
On Sun, Apr 26, 2009 at 1:03 PM, Beman Dawes <bdawes@acm.org> wrote:
It seems to me that it is a normal practice for a web site to track usage of page visits and visitors. But I'm quite uncomfortable with offline tracking. Thus I like your suggestion that a distinction be made between the distribution package and the web site.
I agree, it has no place offline. It could actually help if some stats from the online tracking were published to this list though. Docs with high traffic (relative to other docs from the same lib) might help indicate people are having a hard time remembering how to use some code, and could use better explaining (or better code) so they remember the first time.
Agreed. Can someone please explain to me what the scripts in use currently are, what they do, and who gets the information they generate? In any case I'm strongly against offline-readable docs having references to external scripts like this, if nothing else it's a real pain if your computer keeps trying to connect when you don't want it too. Just my 2c, John.
2009/4/27 John Maddock <john@johnmaddock.co.uk>:
Can someone please explain to me what the scripts in use currently are, what they do, and who gets the information they generate?
I don't think the gil pages are tracking anything, as they don't call 'urchinTracker'. So it looks like they just forgot to remove the script tags when migrating to boost. But it does seem to be actively used in boost build.
In any case I'm strongly against offline-readable docs having references to external scripts like this, if nothing else it's a real pain if your computer keeps trying to connect when you don't want it too.
It shouldn't be too hard to add a check to inspect. I think the only allowed external links should be in 'a' tags. Maybe also for some 'link' tags depending on their 'rel' attribute, although that will require better parsing. Daniel
2009/4/27 Daniel James <daniel_james@fmail.co.uk>:
It shouldn't be too hard to add a check to inspect. I think the only allowed external links should be in 'a' tags. Maybe also for some 'link' tags depending on their 'rel' attribute, although that will require better parsing.
I've just added a check to inspect and removed the google analytics script tags from gil. Apart from these script tags the inspect script is now flagging a lot of external images. Almost all of these are either the boost logo or W3C valid html logos. For all the boost logo images I've changed them to use a local copy. I guess we can include a copy of the W3C logos with boost, I think their only redistribution requirement is that they're only used on valid pages, so I guess we're allowed to include them, but they won't be under the boost license - does that matter? Boost.Graph also uses a lot of external images which seem to be mostly charts generated by a php script. Daniel
On Wed, Apr 29, 2009 at 10:19:17PM +0100, Daniel James wrote:
2009/4/27 Daniel James <daniel_james@fmail.co.uk>:
It shouldn't be too hard to add a check to inspect. I think the only allowed external links should be in 'a' tags. Maybe also for some 'link' tags depending on their 'rel' attribute, although that will require better parsing.
I've just added a check to inspect and removed the google analytics script tags from gil.
Great!
Apart from these script tags the inspect script is now flagging a lot of external images. Almost all of these are either the boost logo or W3C valid html logos. For all the boost logo images I've changed them to use a local copy.
That's also good news. Thanks for this, -Stev
John Maddock wrote:
----- Original Message ----- From: "Cory Nelson" <phrosty@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, April 26, 2009 10:31 PM Subject: Re: [boost] google-analytics and privacy
On Sun, Apr 26, 2009 at 1:03 PM, Beman Dawes <bdawes@acm.org> wrote:
It seems to me that it is a normal practice for a web site to track usage of page visits and visitors. But I'm quite uncomfortable with offline tracking. Thus I like your suggestion that a distinction be made between the distribution package and the web site.
I agree, it has no place offline. It could actually help if some stats from the online tracking were published to this list though. Docs with high traffic (relative to other docs from the same lib) might help indicate people are having a hard time remembering how to use some code, and could use better explaining (or better code) so they remember the first time.
Agreed.
Can someone please explain to me what the scripts in use currently are, what they do,
Do you have any questions not already answered at http://www.google.com/analytics/ ?
and who gets the information they generate?
For Boost.Build docs, I get the information. I don't know about others. - Volodya
On Sent: Monday, April 27, 2009 6:55 AM Vladimir Prus wrote:
John Maddock wrote:
From: "Cory Nelson" <phrosty@gmail.com>
On Sun, Apr 26, 2009 at 1:03 PM, Beman Dawes <bdawes@acm.org> wrote:
It seems to me that it is a normal practice for a web site to track [snip] I agree, it has no place offline. It could actually help if some stats from the online tracking were published to this list though. [snip] Agreed.
Can someone please explain to me what the scripts in use currently are, what they do,
Do you have any questions not already answered at http://www.google.com/analytics/ ?
and who gets the information they generate?
For Boost.Build docs, I get the information. I don't know about others.
If it is of any value in considering how to proceed, I use NoScript in Firefox and I mark google-analytics as untrusted, so I never run any of their code when browsing. As a rule, I don't like companies tracking my activities, so I disable as much as possible. I wouldn't mind Boost tracking my activities when browsing the docs, but I can't enable google-analytics for that one case (as far as I'm aware). Any others doing the same will also deny you usage statistics. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
on Sun Apr 26 2009, Beman Dawes <bdawes-AT-acm.org> wrote:
On Sat, Apr 25, 2009 at 6:36 PM, Steve M. Robbins <steve@sumost.ca> wrote:
A compromise is possible: remove the tracking from the source files, used in offline reading, but add it for docs located on the web site, as tools/build/v2/roll.sh appears to do.
It seems to me that it is a normal practice for a web site to track usage of page visits and visitors. But I'm quite uncomfortable with offline tracking. Thus I like your suggestion that a distinction be made between the distribution package and the web site.
I agree with Beman and am surprised to even hear that offline tracking was possible, much less done. I'm sure it's inadvertent in our case, and doesn't actually give us information we'd want anyway. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Steve M. Robbins wrote:
On Fri, Apr 24, 2009 at 10:55:42AM +0400, Vladimir Prus wrote:
Steve M. Robbins wrote:
On Thu, Apr 23, 2009 at 11:49:13PM -0500, Steve M. Robbins wrote:
Beman Dawes wrote: > I've gotten badly sidetracked by non-Boost work, but would like to get > the 1.39.0 beta out tomorrow if at all possible. > > Are there any known showstoppers?
Many of the HTML doc files have
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
in them. Some will find it inappropriate [1,2] to track their reading habits. I imagine it might cause a problem for those who want to read offline.
Can the docs be re-generated before release without these scripts?
Forgot to list the offending files:
libs/gil/doc (basically all of them) tools/build/v2/index.html
(this is true of both release and trunk)
I am unsure that privacy concerns there are might be. I don't think Google provides per-IP data at all, and even if they did, it's unclear why the list of documentation pages read counts as minimally sensitive information.
Certainly many people will not be bothered by this, but some will: I posted because I was asked to remove the script from Debian [1].
A compromise is possible: remove the tracking from the source files, used in offline reading, but add it for docs located on the web site, as tools/build/v2/roll.sh appears to do.
I have done so. - Volodya
Beman Dawes wrote:
Are there any known showstoppers?
Not a showstopper, but here's a patch to stop spirit warnings in serialization: http://sodium.resophonic.com/git/boost_cookbook/plain/serialization.patch I'll commit if you like. on recent gccs, boost.python is pretty noisy as well, and graph complains about these: Building CXX object libs/graph/src/CMakeFiles/boost_graph-mt-shared-debug.dir/read_graphviz_spirit.cpp.o In file included from /usr/local/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward/hash_set:59, from /home/troy/Projects/boost/git/boost/boost/graph/adjacency_list.hpp:25, from /home/troy/Projects/boost/git/boost/boost/graph/graphviz.hpp:24, from /home/troy/Projects/boost/git/boost/libs/graph/src/read_graphviz_spirit.cpp:28: /usr/local/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. -t
troy d. straszheim wrote:
Beman Dawes wrote:
Are there any known showstoppers?
Not a showstopper, but here's a patch to stop spirit warnings in serialization:
http://sodium.resophonic.com/git/boost_cookbook/plain/serialization.patch
I'll commit if you like.
Sometime ago I included changes like this and had a few problems. In particular, Borland serialization will only build with the 1.6x version of spirit. If one makes these changes then the library won't build at least for borland. I don't know which if any other compilers are affected. I had some other problems with this but was unable to convince anyone that there was any real problem so I just backed out the changes and lived with warning. Robert Ramey
on recent gccs, boost.python is pretty noisy as well, and graph complains about these:
Building CXX object libs/graph/src/CMakeFiles/boost_graph-mt-shared-debug.dir/read_graphviz_spirit.cpp.o In file included from /usr/local/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward/hash_set:59, from /home/troy/Projects/boost/git/boost/boost/graph/adjacency_list.hpp:25, from /home/troy/Projects/boost/git/boost/boost/graph/graphviz.hpp:24, from /home/troy/Projects/boost/git/boost/libs/graph/src/read_graphviz_spirit.cpp:28: /usr/local/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
-t
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Fri Apr 24 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
troy d. straszheim wrote:
Beman Dawes wrote:
Are there any known showstoppers?
Not a showstopper, but here's a patch to stop spirit warnings in serialization:
http://sodium.resophonic.com/git/boost_cookbook/plain/serialization.patch
I'll commit if you like.
Sometime ago I included changes like this and had a few problems. In particular, Borland serialization will only build with the 1.6x version of spirit. If one makes these changes then the library won't build at least for borland. I don't know which if any other compilers are affected. I had some other problems with this but was unable to convince anyone that there was any real problem so I just backed out the changes and lived with warning.
Are we still supporting Borland? If so, can you use conditional compilation to suppress the error on the other compilers? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Apr 24 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
troy d. straszheim wrote:
Beman Dawes wrote:
Are there any known showstoppers?
Not a showstopper, but here's a patch to stop spirit warnings in serialization:
http://sodium.resophonic.com/git/boost_cookbook/plain/serialization.patch
I'll commit if you like.
Sometime ago I included changes like this and had a few problems. In particular, Borland serialization will only build with the 1.6x version of spirit. If one makes these changes then the library won't build at least for borland. I don't know which if any other compilers are affected. I had some other problems with this but was unable to convince anyone that there was any real problem so I just backed out the changes and lived with warning.
Are we still supporting Borland? If so, can you use conditional compilation to suppress the error on the other compilers?
I looked into this, but couldn't figure out a way to do it. Robert Ramey
participants (13)
-
Andrew Sutton -
Beman Dawes -
Cory Nelson -
Daniel James -
David Abrahams -
Eric Niebler -
jbosboom＠uci.edu -
John Maddock -
Robert Ramey -
Steve M. Robbins -
Stewart, Robert -
troy d. straszheim -
Vladimir Prus