<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 3:30 PM, Matthew Woehlke <span dir="ltr"><<a href="mailto:mw_triad@users.sourceforge.net" target="_blank">mw_triad@users.sourceforge.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Possibly :-). I'd tend to agree with Stephen that this isn't the best place to get into a discussion of git history rewriting. But I'll also drop <a href="https://help.github.com/articles/remove-sensitive-data" target="_blank">https://help.github.com/<u></u>articles/remove-sensitive-data</a> as a possible place to start looking.</blockquote>
<div><br></div><div>Thanks! I also agree. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So far, out of what you listed, the documentation related stuff is most<br>
interesting to me as an upstream trying to find upstreamable (or generally<br>
useful) stuff in BASIS, or trying to find the gaps in cmake which are<br>
suitable for closing in cmake itself.<br>
</blockquote>
<br>
Great, I too believe the basis_add_doc(), basis_add_doxygen_doc(), and<br>
basis_add_sphinx_doc() functions and related files would be perfect<br>
candidates to put in the "Modules" folder of CMake itself after whatever<br>
other minor tweaks are necessary.<br>
</blockquote>
<br></div>
I didn't look at it yet, but to be "optimally" useful I would hope that an implementation of generating doxygen documentation would:<br></blockquote><div><br></div><div>What we have won't be "optimally" useful, but it is "very" useful. I think if it is integrated the additional steps to reach "optimal" usefulness could be added over time.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- allow the user to specify the <a href="http://doxyfile.in" target="_blank">doxyfile.in</a> (probably as a well-known variable; most projects will want to set it once) in addition to having a default one<br></blockquote>
<div><br></div><div>This is implemented. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- implement two-step generation of tag files followed by the actual documentation </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- allow the user to provide a list of library names to be used as input tag files (assuming those targets use the same mechanism to generate documentation) </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- implement the above in a manner that allows the user some mechanism to define 'custom' targets with their own tag file(s) for external documentation </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- allow for circular linking (this is why tags and doc need to be separate steps; the tags have no dependencies, but the docs depend on the referenced tags; splitting the two avoids creating dependency cycles)<br></blockquote>
<div><br></div><div>These steps seem like a fairly complicated and specialized use case rather than a typical one. Perhaps I am mistaken?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In particular, I have a project where I want to be able to link to Qt documentation, but due to deficiencies in how Qt generates its tag file, I actually need to generate my own supplementary tag file. I want to be able to use this just by listing "Qt" as a documentation dependency.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><div><br></div>The current version of the doxygen component wraps the support provided in a normal doxyfile and also provides several filters which allow a few extra languages to be documented, including the CMake language itself. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Here is the full documentation of the <a href="http://opensource.andreasschuh.com/cmake-basis/apidoc/latest/DocTools_8cmake.html#a6a37a66eb28f7969ef27b004f8faaa3a">doxygen component</a> and the <a href="http://opensource.andreasschuh.com/cmake-basis/apidoc/latest/DocTools_8cmake.html#a628468ae6c7b29570a73a2d63eebf257">sphinx component</a>, of course the documentation I link to was generated in doxygen using the very tools we are discussing. :-)<br clear="all">
<div><div><br></div>Cheers!<div>Andrew Hundt</div></div><div> </div></div></div></div>