On 2013-12-19 11:21, Brad King wrote:
On 12/18/2013 12:13 PM, Matthew Woehlke wrote:
Does this mean one cannot e.g. use the CMake extensions and/or link to
topics in CMake's documentation (provided a known location of the same)?
Correct. Sphinx does not support magic cross-referencing to
On 01/08/2014 01:52 PM, Matthew Woehlke wrote:
On 2013-12-19 11:21, Brad King wrote:
Sphinx does not support magic cross-referencing to external documents.
If that's really true, that's a pretty big drawback of docutils vs. e.g.
doxygen, which has very good support for external references.
On 2014-01-08 15:35, Brad King wrote:
On 01/08/2014 01:52 PM, Matthew Woehlke wrote:
On 2013-12-19 11:21, Brad King wrote:
Sphinx does not support magic cross-referencing to external documents.
If that's really true, that's a pretty big drawback of docutils vs. e.g.
doxygen, which has very
On 01/08/2014 04:00 PM, Matthew Woehlke wrote:
To be clear, I meant *only* the '#.rst' syntax (i.e. the code to extract
the reST markup from a CMake module). I would not expect *that* to
change again?
It may. It already supports a version with long bracket comments:
On 12/18/2013 12:13 PM, Matthew Woehlke wrote:
Does this mean one cannot e.g. use the CMake extensions and/or link to
topics in CMake's documentation (provided a known location of the same)?
Correct. Sphinx does not support magic cross-referencing to external
documents. Generating such links
On 12/10/2013 04:57 PM, Matthew Woehlke wrote:
Thanks. Are there any guidelines on documenting the parameters of CMake
functions/macros? I didn't see that in the mentioned document.
No convention has been established so there is none to document yet.
We can see if any dominant form emerges.
On 12/10/2013 04:46 PM, Matthew Woehlke wrote:
Why is the copyright notice *after* the documentation?
In the old documentation system the extractor only supported
docs in the leading comment so the notice *had* to be later.
Now it is just a convention.
-Brad
--
Powered by www.kitware.com
On 2013-12-18 11:52, Brad King wrote:
On 12/10/2013 04:46 PM, Matthew Woehlke wrote:
Why is the copyright notice *after* the documentation?
In the old documentation system the extractor only supported
docs in the leading comment so the notice *had* to be later.
Now it is just a convention.
On 2013-12-18 11:52, Brad King wrote:
On 12/10/2013 04:57 PM, Matthew Woehlke wrote:
Thanks. Are there any guidelines on documenting the parameters of CMake
functions/macros? I didn't see that in the mentioned document.
No convention has been established so there is none to document yet.
We
On 2013-11-22 15:49, Brad King wrote:
On 11/22/2013 03:24 PM, Matthew Woehlke wrote:
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation immediately preceding the function definitions,
On 2013-11-22 15:49, Brad King wrote:
On 11/22/2013 03:24 PM, Matthew Woehlke wrote:
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation immediately preceding the function definitions,
Now that CMake is using RST for documentations, is there a good guide
for how to document modules that mainly provide new functions?
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation
On 11/22/2013 03:24 PM, Matthew Woehlke wrote:
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation immediately preceding the function definitions,
rather than all at the top.
See
13 matches
Mail list logo
