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 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 go
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 referen
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 exte
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 link
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 ca
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.
C
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
Visi
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 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,
ra
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,
ra
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
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
13 matches
Mail list logo
