[lldb-dev] LLDB Website

[Pavel Labath via lldb-dev]

On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wrote:
> 
> 
> On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere <jonas at devlieghere.com 
> <mailto:jonas at devlieghere.com>> wrote:
> 
> 
> 
>     On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner <tanyalattner at llvm.org
>     <mailto:tanyalattner at llvm.org>> wrote:
> 
> 
> 
>>         On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere
>>         <jonas at devlieghere.com <mailto:jonas at devlieghere.com>> wrote:
>>
>>
>>
>>         On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner
>>         <tanyalattner at llvm.org <mailto:tanyalattner at llvm.org>> wrote:
>>
>>
>>
>>>             On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere
>>>             <jonas at devlieghere.com <mailto:jonas at devlieghere.com>> wrote:
>>>
>>>             Hey Tanya,
>>>
>>>             On Tue, Apr 23, 2019 at 11:51 Tanya Lattner
>>>             <tanyalattner at llvm.org <mailto:tanyalattner at llvm.org>> wrote:
>>>
>>>                 Jonas,
>>>
>>>                 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.
>>
>>
>>         Perfect!
>>
>>
>>             So I am able to generate the cpp reference docs:
>>             https://lldb.llvm.org/cpp_reference/index.html
>>
>>             However, the main website links to
>>             https://lldb.llvm.org/cpp_reference/html/index.html. Do
>>             you want the html in that url? I can change the alias. We
>>             strip for other doxygen.
>>
>>
>>         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`.
>>
>>         https://lldb.llvm.org/cpp_reference/index.html
> 
>         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...
> 

I think it would be good to avoid that...

pl