John Snow <js...@redhat.com> writes:
> Add a special :ifcond: option that allows us to annotate the
> definition-level conditionals.
>
> RFC: This patch renders IFCOND information in two places, because I'm
> undecided about how to style this information. One option is in the
> signature bar, and another option is in an eye-catch, like :deprecated:
> or :unstable:.
>
> A benefit to having this be a directive option is that we can put it in
> the signature bar, the QAPI index, etc. However, if we merely want it in
> the content section, a directive would work just as well,
> e.g. ".. qapi:ifcond:: CONFIG_LINUX".
You haven't implemented conditionals that aren't at definition-level.
As I said elsewhere, that's okay for now. All I want to say here is
that implementing it might influence your preference on how to do the
definition-level conditionals. That's fine, we can revisit this.
> (Though, having it be in the same containing box as the unstable/ifcond
> boxes might require some extra fiddling/post-processing to
> achieve. Generally, the less docutils tree muddling I have to do, the
> happier I am.)
>
> The syntax of the argument is currently undefined, but it is possible to
> parse it back down into constituent parts to avoid applying literal
> formatting to "AND" or "&&" or whichever syntax we formalize. (Or, in
> the future, applying cross-reference links to the config values for
> additional reading on some of those build options. Not for this series.)
>
> "Vote now on your phones!"
Find my vote here:
Message-ID: <87zfhya0is....@pond.sub.org>
https://lore.kernel.org/qemu-devel/87zfhya0is....@pond.sub.org/
> Signed-off-by: Harmonie Snow <harmo...@gmail.com>
> Signed-off-by: John Snow <js...@redhat.com>
