On Thu, Mar 07, 2019 at 01:30:39PM +0000, Peter Maydell wrote: > On Thu, 7 Mar 2019 at 13:18, Cleber Rosa <cr...@redhat.com> wrote: > > > > On Thu, Mar 07, 2019 at 12:29:08PM +0000, Peter Maydell wrote: > > > I'm still not clear how this helps. Either the top level > > > index file has everything in it (in which case it's no good > > > for 'make install'), or we just have separate manuals per > > > > IIRC, it shouldn't matter what the "top level" index file (index.rst) > > has, because it's the resulting build (not the source index.rst) that > > will be 'make install'ed. Or am I missing something? > > I guess what I'm trying to ask is whether this tags > approach results in different (or differently structured) > final documents being produced, or whether it's just a > different mechanism that gives the same end result. >
I was pursuing the same result, as I understand the requirements are sound and well defined, that is, we do want multiple final documents produced in the non-readthedocs.org environment. > > I don't see the multiple listings you mention here > > I think I was looking at the sketch you had in a previous > email rather than the more fleshed-out code in the git repo. > Oh, OK. > > Anyway, if it's not clear to you as it's to me, then I'm probably > > biased or missing something. > > Well, I'm also a bit biased here, in that this is v3 of this > patchset that's been on the list using this approach for > a month, and I was planning to apply it to master today > so that it could be in before the softfreeze on Tuesday > next week. So late-breaking suggestions for significant > restructurings are essentially saying "we should postpone > this to 4.1" :-( > I apologize for not looking at this before... honestly speaking, my bandwidth and efficiency doesn't allow me look at most patches :). It was only a CC on this v3 that caught my attention. Anyway, I don't want to disrupt progress, and I do believe in incremental betterment. I have plans to add Python API docs once the "python" directory structure gets in, so I might as well suggest improvements in the form of patches later on. Feel free to ignore this suggestion for now. > thanks > -- PMM Best regards, - Cleber.
