1.32 documentation issue
When using boost libraries, It is my custom to peruse the local copy of boost documentation on my hard drive. This avoids necessity to be connected to www.boost.org all the time which can be inconvenient in lots of cases. The following scenario takes me a way from my local copy. a) C:\boost_RC_1_32_0\index.htm b) select libraries c) select function programming section d) select function e) At this point I am automatically redirected to www.boost.org I think I should be redirected to ./function.html instead. Robert Ramey
Actually after poking around in other pages - specifically the spirit documentation I find that its not uncommon for links to point to www.boost.org rather than have a relative path that would keep the session in the same documentation tree. This would seem to conflict with the idea that boost should be usable as a CDROM distribution. I don't know if there's time for this but the inspect should be enhanced to check for this and all the offending global links should be altered to relative ones. Robert Ramey "Robert Ramey" <ramey@rrsd.com> wrote in message news:cm8g8d$u7i$1@sea.gmane.org...
When using boost libraries, It is my custom to peruse the local copy of boost documentation on my hard drive. This avoids necessity to be connected to www.boost.org all the time which can be inconvenient in lots of cases.
The following scenario takes me a way from my local copy.
a) C:\boost_RC_1_32_0\index.htm b) select libraries c) select function programming section d) select function e) At this point I am automatically redirected to www.boost.org
I think I should be redirected to ./function.html instead.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 12:39 PM 11/2/2004, Robert Ramey wrote:
Actually after poking around in other pages - specifically the spirit documentation I find that its not uncommon for links to point to www.boost.org rather than have a relative path that would keep the session in the same documentation tree. This would seem to conflict with the idea that boost should be usable as a CDROM distribution.
I don't know if there's time for this but the inspect should be enhanced to check for this and all the offending global links should be altered to relative ones.
We tried to do that at one time, but gave up because it is a bit tricky. Some absolute www.boost.org references are correct, such as to the LICENSE file, so it isn't as simple as just searching for "www.boost.org/" in .htm? files. I've just taken a look (using grep) at the CVS RC (not the tarball) and it seems that while the problem does happen, particularly in spirit and graph libraries, it isn't really horrible. I'd say we can wait until after the release ships, then see if we can come up with some logic that doesn't generate a lot of false positives. --Beman
Beman Dawes writes:
At 12:39 PM 11/2/2004, Robert Ramey wrote:
Actually after poking around in other pages - specifically the spirit documentation I find that its not uncommon for links to point to www.boost.org rather than have a relative path that would keep the session in the same documentation tree. This would seem to conflict with the idea that boost should be usable as a CDROM distribution.
I don't know if there's time for this but the inspect should be enhanced to check for this and all the offending global links should be altered to relative ones.
We tried to do that at one time, but gave up because it is a bit tricky. Some absolute www.boost.org references are correct, such as to the LICENSE file, so it isn't as simple as just searching for "www.boost.org/" in .htm? files.
IMO at least all www.boost.org/libs/* references should be changed to relative ones.
I've just taken a look (using grep) at the CVS RC (not the tarball) and it seems that while the problem does happen, particularly in spirit and graph libraries, it isn't really horrible.
I'd say we can wait until after the release ships, then see if we can come up with some logic that doesn't generate a lot of false positives.
I'd like to get the ones we can detect fixed for the release (although I probably won't bother with modifying the inspect tool for now). -- Aleksey Gurtovoy MetaCommunications Engineering
Robert Ramey writes:
Actually after poking around in other pages - specifically the spirit documentation I find that its not uncommon for links to point to www.boost.org rather than have a relative path that would keep the session in the same documentation tree.
Robert, This is one thing in which a CVS checkout (which you are examining) differs from the tarball -- in a checkout many of these links redirect to Boost.org because the BoostBook-generated documentation is not there. In the tarball, the placeholder files which do the redirect are overridden by the actual BoostBook-generated content. That said, even in the tarball there is a number of links which use the absolute www.boost.org notation without a good reason. I just fixed the easy ones on the branch. If someone wants to tackle the issue of how to handle the ones from the documents which potentially might reside outside of Boost (Spirit docs for instance, or conference papers), please be my guest. -- Aleksey Gurtovoy MetaCommunications Engineering
"Robert Ramey" <ramey@rrsd.com> writes:
When using boost libraries, It is my custom to peruse the local copy of boost documentation on my hard drive. This avoids necessity to be connected to www.boost.org all the time which can be inconvenient in lots of cases.
The following scenario takes me a way from my local copy.
a) C:\boost_RC_1_32_0\index.htm b) select libraries c) select function programming section d) select function e) At this point I am automatically redirected to www.boost.org
I think I should be redirected to ./function.html instead.
It goes to the web intentionally, on the idea that developers who don't want to build the documentation (which involves installing an extensive toolchain) should be able to get to the Boost.Function documentation. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (5)
-
Aleksey Gurtovoy -
Beman Dawes -
David Abrahams -
Robert Ramey