On 2014-01-27 14:48, Andrew Hundt wrote:
On Thu, Jan 23, 2014 at 4:14 AM, Stephen Kelly wrote:
Andrew Hundt wrote:
I'm not well versed with the guts of git but are there any good
ways to do some cleanup?
If you have to ask, the details probably not something worth discussing
here. Adding a commit removing them is not going to help. My previous paste
showed that some of the biggest files are already deleted in the current
tree.
The level of my question my have been underestimated, because I was
referring to git commands that strip data from the history. I created an
issue to take another look at the size, thanks for the feedback.
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 https://help.github.com/articles/remove-sensitive-data as a
possible place to start looking.
So far, out of what you listed, the documentation related stuff is most
interesting to me as an upstream trying to find upstreamable (or generally
useful) stuff in BASIS, or trying to find the gaps in cmake which are
suitable for closing in cmake itself.
Great, I too believe the basis_add_doc(), basis_add_doxygen_doc(), and
basis_add_sphinx_doc() functions and related files would be perfect
candidates to put in the "Modules" folder of CMake itself after whatever
other minor tweaks are necessary.
I didn't look at it yet, but to be "optimally" useful I would hope that
an implementation of generating doxygen documentation would:
- allow the user to specify the doxyfile.in (probably as a well-known
variable; most projects will want to set it once) in addition to having
a default one
- implement two-step generation of tag files followed by the actual
documentation
- 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)
- 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
- 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)
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.
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
