That's the issue - lldb-python-doc depends on liblldb. From docs/CMakeLists.txt:
if(EPYDOC_EXECUTABLE)
find_program(DOT_EXECUTABLE dot)
if(DOT_EXECUTABLE)
set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath
${DOT_EXECUTABLE})
endif()
set(DOC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/doc")
file(MAKE_DIRECTORY "${DOC_DIR}")
#set(ENV{PYTHONPATH}
${CMAKE_CURRENT_BINARY_DIR}/../../../lib/python2.7/site-packages)
add_custom_target(lldb-python-doc
${EPYDOC_EXECUTABLE}
--html
lldb
-o ${CMAKE_CURRENT_BINARY_DIR}/python_reference
--name "LLDB python API"
--url "http://lldb.llvm.org";
${EPYDOC_OPTIONS}
DEPENDS swig_wrapper liblldb
WORKING_DIRECTORY
${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages
COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM
)
endif(EPYDOC_EXECUTABLE)
> -Original Message-
> From: lldb-dev On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, April 24, 2019 1:16 AM
> To: Jonas Devlieghere ; Tanya Lattner
>
> Cc: LLDB
> Subject: [EXT] Re: [lldb-dev] LLDB Website
>
> On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wrote:
> >
> >
> > On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere
> > mailto:jo...@devlieghere.com>> wrote:
> >
> >
> >
> > On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner > > wrote:
> >
> >
> >
> >> On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere
> >> mailto:jo...@devlieghere.com>> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner
> >> mailto:tanyalatt...@llvm.org>> wrote:
> >>
> >>
> >>
> >>> On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere
> >>> mailto:jo...@devlieghere.com>>
> wrote:
> >>>
> >>> Hey Tanya,
> >>>
> >>> On Tue, Apr 23, 2019 at 11:51 Tanya Lattner
> >>> mailto:tanyalatt...@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 tha
