Use path-constant in Jamfile #86
Conversation
|
Don't do unnecessary |
|
An automated preview of the documentation is available at https://86.utility.prtest.cppalliance.org/libs/utility/index.html |
alandefreitas
force-pushed
the
reference_glob
branch
from
38c8ba6 to
5ae025b
Compare
|
Oops... I was trying to ensure it looked exactly like boost.core and left that behind. The new version also worked locally. |
|
This broke styling and links to images in my local build. |
|
The problem is it generates links such as |
|
I'll look for a solution that works directly on the docker images then. |
|
Other libraries seem to work fine with relative paths, so it seems they should work for Boost.Utility as well. At least, it isn't clear what's the difference between the system where the official docs are built and our local systems. |
Exactly. Apart from the According to Peter, we should never use relative paths in a Jamfile. This implies that boost.core was just lucky. But it's not the only library where we see relative paths. And we already replicated the error by running it from the root path, so I don't think the docker image will help much, even though I'll keep trying. |
|
I have no idea what's going on here; the PR says "use path-constant" but doesn't use |
I might have completely misunderstood what you said then. I'm so sorry. Isn't BOOST_ROOT a path-constant? I imagined if we defined the path-constant in our own Jamfile instead of just using a path-constant defined somewhere else, then the new solution would be as hard-coded as before. I probably misunderstood you then. It didn't work anyway. |
|
Use the Since your Jamfile is in
|
|
I've pushed 9d1284e that works for me locally. I think, this is what Peter meant. The important difference from this PR is that |
|
So... is different from ? 😓 |
|
Sometimes, yes. Most parts of b2 (all of the built-in rules, for instance) interpret a relative path as relative to the current Jamfile. However, other parts of it interpret it relative to the current directory. (E.g. the path.glob rule.) In addition, if you pass the relative path as-is to an external program, the external program will again interpret it against the current directory. It's safest to use It is what it is. |
|
Looks like 9d1284e did the trick. Can we update the website? |
|
Yes, @alandefreitas please create pull request to https://github.com/boostorg/website/tree/master/doc/libs for 1_78_0/libs/utility with the correct generated content |
|
Oh... |
|
It should have the same layout as That is, |
|
Yes, see the other directories for examples |
5 participants
The previous jamfile was counting on the git layout instead of the boost release layout. We can replicate the error with
b2 libs/utility/docfrom<boost root>, which still tries to generate the doc in<boost root>/libs/utility/doc/htmland<boost root>/bin.v2/libs/utility/doc/htmlstill keeps temporary files, but it fails to find the links.According to Peter, we should use path-constant instead of hardcoding relative paths in the jamfile. The reason is relative paths are often but not always relative to the Jamfile location. This PR uses BOOST_ROOT from Jamroot.
b2 libs/utility/b2 libs/utility/docwork from<boost root>now (locally).What's funny is
b2 libs/core/docworks with both layouts and boost.utility uses almost the same commands script.