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

[Stephen Kelly]

Andrew Hundt wrote:

> CMake BASIS is a set of utilities and standards created with the goal of
> making CMake projects and libraries very easy to create, share, and reuse.

Hello,

There seems to be several years of development behind this already. Is it 
newly public, or newly publicized? I've never heard of it before.

> 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: 5f2d4a7 Install CMake package configuration files in 
<prefix>/lib/cmake/<package>/ instead of <prefix>/lib/<package>/cmake/.
100644 blob 6e0f741b61d233498c01b185e3896c6e5ed4d731 
example/MatlabITKExample/data/jakob_stripped_onlyGM_orderedlabels_DS.img
Size: 1008864

Commit: 3079349 #300 resolve ambiguity between basisproject update and 
basisproject upgrade
100644 blob 3143bd67996e96e0172dc341162915ee04b983c5 
include/basis/gtest/gtest.h
Size: 801700

Commit: 6a2aadf Update links to point to GitHub hosted pages instead of 
SBIA. Directory structure has slightly changed. Updated PDF for download.
100644 blob 9bdcf2e1283b2873055737574722a91187fd88d4 
apidoc/latest/Doxytags.apidoc
Size: 630210

Commit: 29aaf00 Renamed branch release-1.0 to basis-1.0.
100644 blob c7d3d6f0054fcec4b3fff9c7c934502d2ed185ca 
include/gmock/gmock.h.in
Size: 500038

Commit: ae92062 Generated from feature/docUsability branch commit 95373d1.
100644 blob 0bfa90df506b4f14a05a32b3cc85828cdabc2b58 
apidoc/latest/argparse_8py_source.html
Size: 494026

Commit: 24725a1 Merge changes from basis-2.1 to trunk, no actual changes 
were made.
100644 blob 2df64bdfc74d1d5ef2456bdce33d232c57146ac8 
doc/BASIS_Software_Manual.pdf
Size: 466358

Commit: 494fa52 Document changes in 2.1.2.
100644 blob 5ca21da0ba339919980127f484edc0df17817d5b 
doc/BASIS_Software_Manual.pdf
Size: 431426

Commit: 9a082f0 Update software manual.
100644 blob a1642c175bb23391f9e97b9ff317098fe51d0e21 doc/BASIS.pdf
Size: 426872

Commit: 11e0090 Merge changes from basis-2.1 branch into trunk.
100644 blob 6a40b05469a38d8e667c5ac9fc5bca6b126079a6 doc/BASIS.pdf
Size: 426680

Commit: 29aaf00 Renamed branch release-1.0 to basis-1.0.
100644 blob aaaeab64a0194691e2effd10ddb122f75dcf6683 
src/utilities/cxx/test.cxx
Size: 389938


> We have included an overview of CMake BASIS below. If you are interested,
> have questions, or wish to contribute we invite you to get in touch with
> us. Also, if any CMake developers are interested in bringing any of this
> functionality upstream into CMake itself we would also love to hear from
> you.

I read some of the docs and some of the code (TargetTools.cmake). My 
understanding my not be complete or correct.

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 think you could know better than we can.

For example, do you consider 

 add_executable(myexe.cpp)

to be good user interface for creating a target called 'myexe', and 
something that CMake should do? Should CMake automatically create 
installation rules for it?

Another example: You have some target-source-file-globbing code. Should that 
be extracted, generalized and upstreamed?

 https://www.mail-archive.com/cmake-developers@cmake.org/msg06725.html

Another example: You have code for adding scripts as executables. What are 
the generic (non-BASIS related) use cases for that? Should CMake be extended 
with similar capabilities somehow? Would it help if an IMPORTED executable 
could be a script?

Another example: Can the documentation utilities be separated from the rest 
of BASIS, made generic and still be useful?

2) Do you generally recommend that CMake users use BASIS from now on, or is 
it something you expect will be niche/mostly used by yourselves?

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. 

BASIS seems to wrap many or most CMake commands which define the 
buildsystem. That was realized to be bad practice in KDE. The new KDE 
Frameworks (KF5) do not have that requirement or practice, and instead the 
regular add_executable CMake commands (and similar) are recommended. CMake 
has been extended (by myself and others) to make that possible without 
losing features. 

This way, not only is interoperability increased, but users of a KF5 package 
can rely on the CMake documentation to understand and reason about code they 
read and write. Further, the buildsystem for KF5 is CMake not 'something on 
top of CMake', which then must be understood. Using CMake directly, and not 
'something on top of CMake' is also a goal of the boost effort to migrate to 
CMake.

Further, wrappers like that can not cleanly offer all of the features of 
wrapped commands, as those commands get updated in CMake. I'm not sure your 
wrappers can handle ALIAS, INTERFACE or OBJECT libraries for example, and it 
seems that 

 add_library(tgt SHARED IMPORTED)

might work, whereas 

 add_library(tgt IMPORTED SHARED)

would not. Ok, it's not documented to work either, but my point is that 
wrappers are not good API proxies.

Any comments on that?

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?


Thanks,

Steve.