[CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools

[Matthew Woehlke]

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