There’s a bunch of people that are annoyed by the missing documentation. I’ve already addressed most of the other comments about the broken URLs and missing top level links, but unfortunately that doesn’t take effect because the website isn’t updating.
Anytime new targets are added, the script has to be modified. Is there a way you can put them all under a top level html target? Or is there a reason not to?
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Yes, so it will do docs-lldb-html on every commit.
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Yes, so it will do docs-lldb-html on every commit.
Let’s keep it without the html. I’ll update a link on the website and add a redirect.
As for python docs, what is required to build those? It’s not showing up as a target for me.
This is probably because you don’t have epydoc installed (sudo pip install epydoc).
I think you’ll have to re-run cmake after for it to pick it up. The corresponding target should then be lldb-python-doc.
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Yes, so it will do docs-lldb-html on every commit.
Let’s keep it without the html. I’ll update a link on the website and add a redirect.
As for python docs, what is required to build those? It’s not showing up as a target for me.
This is probably because you don’t have epydoc installed (sudo pip install epydoc).
I think you’ll have to re-run cmake after for it to pick it up. The corresponding target should then be lldb-python-doc.
Well installing epydoc did the trick, but I don’t think the doxygen script is the right place for this target. I have not dug into it yet but it appears to require some LLVM libraries and is building those. I’m letting it finish to verify it builds but I’ll have to sort out the best way of doing this on the server. We have other scripts that generate other documentation that build parts of LLVM. Ideally, I would want to leverage that and reduce build times.
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Yes, so it will do docs-lldb-html on every commit.
Let’s keep it without the html. I’ll update a link on the website and add a redirect.
As for python docs, what is required to build those? It’s not showing up as a target for me.
This is probably because you don’t have epydoc installed (sudo pip install epydoc).
I think you’ll have to re-run cmake after for it to pick it up. The corresponding target should then be lldb-python-doc.
Well installing epydoc did the trick, but I don’t think the doxygen script is the right place for this target. I have not dug into it yet but it appears to require some LLVM libraries and is building those. I’m letting it finish to verify it builds but I’ll have to sort out the best way of doing this on the server. We have other scripts that generate other documentation that build parts of LLVM. Ideally, I would want to leverage that and reduce build times.
Yeah, the annoying thing about the Python documentation is that it builds the C++ API, then runs swig to generate the Python wrapper, and finally generates the docs from that.
I wonder if we can just use the static bindings that are checked-in instead. I will look into that later today/tomorrow.
Ignore what I said before as these do need to be separate targets. It appears the new targets are running doxygen. This isn’t something we typically do as a post commit hook since it takes awhile. I’ll need to do this via the doxygen nightly script. Any concerns?
That sounds perfect. Can we still do the regular website post commit?
Yes, so it will do docs-lldb-html on every commit.
Let’s keep it without the html. I’ll update a link on the website and add a redirect.
As for python docs, what is required to build those? It’s not showing up as a target for me.
This is probably because you don’t have epydoc installed (sudo pip install epydoc).
I think you’ll have to re-run cmake after for it to pick it up. The corresponding target should then be lldb-python-doc.
Well installing epydoc did the trick, but I don’t think the doxygen script is the right place for this target. I have not dug into it yet but it appears to require some LLVM libraries and is building those. I’m letting it finish to verify it builds but I’ll have to sort out the best way of doing this on the server. We have other scripts that generate other documentation that build parts of LLVM. Ideally, I would want to leverage that and reduce build times.
Yeah, the annoying thing about the Python documentation is that it builds the C++ API, then runs swig to generate the Python wrapper, and finally generates the docs from that.
I wonder if we can just use the static bindings that are checked-in instead. I will look into that later today/tomorrow.
Right, so the reason is that we don’t have the static bindings on llvm.org (we have them for swift-lldb on GitHub).
Maybe we should check them in upstream too? That’s something the community will have to weigh in on…
Ignore what I said before as these do need to be
separate targets. It appears the new targets are
running doxygen. This isn’t something we typically do
as a post commit hook since it takes awhile. I’ll
need to do this via the doxygen nightly script. Any
concerns?
That sounds perfect. Can we still do the regular website
post commit?
Yes, so it will do docs-lldb-html on every commit.
Let's keep it without the html. I'll update a link on the
website and add a redirect.
As for python docs, what is required to build those? It's
not showing up as a target for me.
This is probably because you don't have `epydoc` installed
(sudo pip install epydoc).
I think you'll have to re-run cmake after for it to pick it
up. The corresponding target should then be `lldb-python-doc`.
Well installing epydoc did the trick, but I don’t think the
doxygen script is the right place for this target. I have not
dug into it yet but it appears to require some LLVM libraries
and is building those. I’m letting it finish to verify it builds
but I’ll have to sort out the best way of doing this on the
server. We have other scripts that generate other documentation
that build parts of LLVM. Ideally, I would want to leverage that
and reduce build times.
Yeah, the annoying thing about the Python documentation is that it
builds the C++ API, then runs swig to generate the Python wrapper,
and finally generates the docs from that.
It should be possible to solve this by tweaking the dependency graph a bit. There's no fundamental reason why you need to build anything in order to run swig. It is purely a textual step -- it ingests header files and interface definitions and spits out python and cpp files. The inputs are present as static checked in source, so the swig step could theoretically be the very first build command that we run.
I wonder if we can just use the static bindings that are checked-in
instead. I will look into that later today/tomorrow.
Right, so the reason is that we don't have the static bindings on llvm.org <http://llvm.org> (we have them for swift-lldb on GitHub).
Maybe we should check them in upstream too? That's something the community will have to weigh in on...
That’s great. I see the Python documentation is online now!
Unfortunately it appears that the Sphinx part still isn’t updating. I pushed a bunch of changes last week and none have made it to the homepage yet. I checked the www-scripts mailing list but I don’t see any failures for LLDB. Do you know what’s up here?