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

[Stephen Kelly]

Andrew Hundt wrote:
>>
>> > Website: http://opensource.andreasschuh.com/cmake-basis/index.html
>> > GitHub: https://github.com/schuhschuh/cmake-basis/
>>
>> The repo is surprisingly large (67 mb) for something like this. I
>> consider such large files in a git repo to be bad practice. This is just
>> the first thing I noticed...
>>
>> Commit: [...]
> 
> 
> Hmm, I hadn't noticed the size before. There are a few powerpoint
> presentations and a PDF manual that probably contribute to the size, there
> are also a couple of small external libraries that are directly committed
> into the tree. The zip version of the release is 2.7 MB which is not quite
> as bad. 

It's not surprising that the sizes are not similar.

> 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.

>> 1) BASIS seems to be doing lots of things. Can you identify what parts of
>> BASIS or what concepts are most valuable/most useful/most missing from
>> CMake etc? 

> I would suggest many of the items from the BASIS CMake
> modules<http://opensource.andreasschuh.com/cmake-basis/apidoc/modules.html>,
> specifically the section labeled "BASIS Modules".

This is also just a list of 'lots of things'. You are more-specific below 
though.

> 
> Some of the specific useful items include:
> 
>    - Additional support for other languages, such as MATLAB and Python 

I always find 'support' to be an awkward word when talking about 
functionality of software. It is far too vague. 

I think you're referring to the script-related targets that can be added 
with basis_add_executable, so leaving a response to there.

>    - Automated packaging and installation of libraries 

'Automated' is also an awkward and almost meaningless word. It would not 
surprise me to be told that 'cpack provides automatic packaging of 
libraries' and that 'cmake provides automatic installation of libraries'.

Are you referring to the fact that your basis_* commands do more than those 
cmake commands which have similar names? If the names were more-
significantly different, would it still be 'automatic'?

>    - basis_add_doc()
>    - Support for doxygen documentation of CMake Code
>    - built in support of documentation tools 

'built-in' is also awkward. If it was not 'built-in', what would it be?

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. 

>> Another example: You have code for adding scripts as executables. What
>> are the generic (non-BASIS related) use cases for that?
> 
> 
> Many projects aren't libraries or installable software for distribution in
> one language, but instead a set of custom utilities that call each other
> via the general Unix philosophy. Also, groups that build embedded software
> or backend software will have scripts that automatically start, monitor,
> deploy, implement, and/or run their software. 

This seems mostly orthogonal to a buildsystem. Can you be more-specific 
about why cmake needs particular knowledge of these scripts? You can run 
scripts with cmake directly.

> Programs based on scripting
> languages also need packaging and installation just like any other
> compiled language if they are to be opened via an icon on a user's system.

I wasn't aware that that was difficult with cpack alone. I'm not overly 
familiar with cpack, but it could be somewhere that the situation can be 
better.

> 
>> Should CMake be extended with similar capabilities somehow?
> 
> I personally believe this could be very useful to quite a few users.

What form would such a change in cmake take? What would a user write, and 
why - what use-case to it satisfy?

>> Would it help if an IMPORTED executable could be a script?
>>
> 
> What would this entail? Is there perhaps another question behind this
> question?

The question behind the question is 'how should a user of cmake define a 
"script target", and why?'.

>> 3) BASIS requires me to use basis_add_executable, KDE4 requires me to use
>> kde4_add_executable, VTK requires me to use vtk_add_executable.

>> my point is that
>> wrappers are not good API proxies.
>>
>> Any comments on that?
>>
> 
> Cool, is there a good reference explaining how wrapped functions can be
> eliminated?

What do you mean by 'a good reference'. If you're looking for a particular 
targetted document, then no, there is not.

In KDE, we looked at what the wrappers were doing, figured out why, and 
found a better way to do it by adding something to cmake upstream so that no 
wrapper was needed anymore. 

Apart from that, what more information would be in 'a good reference'? Given 
that eliminating a wrapper depends on what the wrapper is going, I doubt 'a 
good reference' could cover all content that a wrapper could contain, or the 
content of the BASIS wrappers in particular. I can't imagine what 'a good 
reference' could possibly contain in this context.

>>
>> 4) BASIS seems to expect settings, flags etc to be written as directory
>> scoped. Modern CMake is increasingly scoped to targets, with directory
>> scoped commands considered only convenience for populating properties on
>> targets.
>>
>>
>> http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html#directory-scoped-commands
>>
>> This is mostly helpful for transitive usage requirements and related
>> CMake concepts.
>>
>> Do you think BASIS would move in a similar direction?
>>
> 
> Yes, I would expect it to follow the direction of CMake. As a side note,
> one thing I've wished for with CMake is an up-to-date style guide, how-to,
> and tutorials capturing the best recommended way to write Modern CMake
> code for a cross platform distributable library.

 http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html
 http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html
 
 http://www.kdab.com/modern-cmake-with-qt-and-boost/

Thanks,

Steve.