<div dir="ltr">Perhaps there is a standard location to "install" the documentation when running the install command for a project?<div><br></div><div>Either way having it as an "index.html" file somewhere on the hard-disk is not very intuitive. It would make much more sense for it to be on a web server where you can access it with a sensible URL.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 1:44 AM Alan W. Irwin <<a href="mailto:Alan.W.Irwin1234@gmail.com">Alan.W.Irwin1234@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-02-20 17:52-0500 Timothy Wrona wrote:<br>
<br>
> I have worked on multiple C++ libraries that are built with CMake and run<br>
> Doxygen to generate HTML documentation. In every one of these libraries,<br>
> the documentation get's built into an "html" folder in the CMake "build"<br>
> directory and never gets looked at by anyone.<br>
><br>
> *Because let's be honest, most people don't like to read documentation at<br>
> all - let alone search for it.*<br>
><br>
> This leads to a few questions:<br>
><br>
>   1.<br>
><br>
>   Is there a standard location to put the documentation once it is built<br>
>   where it makes it very clear to the users of a library that documentation<br>
>   is available for a library?<br>
>   2.<br>
><br>
>   How can I ensure that every time my library is built, the documentation<br>
>   will be *automatically *updated and placed in this standard location?<br>
>   3.<br>
><br>
>   Is there any standard way to keep past versions of documentation for<br>
>   reference in case someone is using an earlier version of the library?<br>
><br>
> I have also posted this question on stack overflow. If you would like, you<br>
> can answer there instead because it may help a wider audience:<br>
> <a href="https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to</a><br>
<br>
I am not aware of any standard responses to your 3 questions above.<br>
<br>
What I do for a couple of my projects that have doxygen-generated<br>
documentation is I have a special custom command/target that copies<br>
the doxygen-generated documentation from the build tree back to a<br>
special directory in the source tree, and I only invoke that target if<br>
I am creating a source tarball.  And similarly for DocBook-generated<br>
documentation.  Furthermore, I configure my VCS in each case to ignore<br>
those generated directories in the source tree so there are no VCS<br>
complications, yet tarball users get a chance to access the generated<br>
documentation.<br>
<br>
Of course, if someone here has a better or more standardized scheme, I would like to hear it.<br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Programming affiliations with the FreeEOS equation-of-state<br>
implementation for stellar interiors (<a href="http://freeeos.sf.net" rel="noreferrer" target="_blank">freeeos.sf.net</a>); the Time<br>
Ephemerides project (<a href="http://timeephem.sf.net" rel="noreferrer" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
software package (<a href="http://plplot.sf.net" rel="noreferrer" target="_blank">plplot.sf.net</a>); the libLASi project<br>
(<a href="http://unifont.org/lasi" rel="noreferrer" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" rel="noreferrer" target="_blank">loll.sf.net</a>);<br>
and the Linux Brochure Project (<a href="http://lbproject.sf.net" rel="noreferrer" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
</blockquote></div>