doc/manpages: add the man pages to the docs

[ru-fu]

Generate the man pages for the lxc command and add them to the reference documentation.

Draft PR for now to see if this works on RTD.
If it does, I'll check if I can group the output a bit better (instead of having 300 pages on the same level in the TOC ;) ).

[tomponline]

Is there somewhere else we can move the downloading of dependencies out to, like a github workflow or a readthedocs hook, as I'd like to avoid building the docs from a version of the client that is different to the one running locally.

[ru-fu]

As discussed - let's change to using lxc for local builds (the tool should be in the path if the environment is set up correctly) and building the tool on RTD (see https://github.com/canonical/lxd/blob/main/.github/workflows/tests.yml#L274 ).

[ru-fu]

It looks like the doc build on GitHub is using the lxc that is already installed on the machine instead of the one that we build. I added a requirement to build the client now, but it's still using the wrong lxc.
Any idea how to get it to use the one from the Go build @tomponline ?

[tomponline]

If you're always building the lxc command based on the local source code version then you could modify the lxc invocation to specify the local build target file rather than just executing lxc and relying on the PATH resolution.

[ru-fu]

If you're always building the lxc command based on the local source code version then you could modify the lxc invocation to specify the local build target file rather than just executing lxc and relying on the PATH resolution.

Yes, but how do I know where the built file is?

lxd/Makefile

Line 41 in 9136ce4

go install -v -tags "$(TAG_SQLITE3)" $(DEBUG) ./lxc

doesn't specify an output file as far as I understand. So it's probably going to the Go path? But that one isn't necessarily specified in an environment variable, or is it?

[tomponline]

You can use the value of go env GOPATH and append /bin to it, e.g.

$(go env GOPATH)/bin/lxc

Alternatively, I believe I linked to it during our meeting, but the github work flows for the client testing use a slightly different invocation:

https://github.com/canonical/lxd/blob/main/.github/workflows/tests.yml#L274

To build the binary in a local directory, so it can be used directly.

[ru-fu]

To build the binary in a local directory, so it can be used directly.

Yes, that's what I'm doing for the RTD build, which works fine - but I don't want to add a second target for building the client to the Makefile.

I'll see if I can get the go env working in Python, thanks!

[tomponline]

To build the binary in a local directory, so it can be used directly.

Yes, that's what I'm doing for the RTD build, which works fine - but I don't want to add a second target for building the client to the Makefile.

I'll see if I can get the go env working in Python, thanks!

Why do you need a 2nd target, cant you do the build in the hook itself?

[ru-fu]

Why do you need a 2nd target, cant you do the build in the hook itself?

We have three different build environments: RTD, local build, and GitHub.

• For RTD, we can't expect the client to be present, so we have to build it - I've added that here: https://github.com/canonical/lxd/pull/12165/files#diff-fcfe063c54dc3ad0fcd2f7bd922a3be96d9826992107e44953df08d186851a50
• For the local build, we expect the client to be built through the Makefile client target (which I added as a prereq for the dcc-setup target) and to be available in the path.
• The GitHub build also uses the Makefile, therefore also runs the client target. So there shouldn't be a need to build the client again - I just need to somehow find it.

[tomponline]

Ah I thought you were just going to build a local lxc for it in all environments.

[ru-fu]

Working now 😄