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

[Andrew Hundt]

On Thu, Jan 23, 2014 at 8:11 AM, Andreas Schuh <andreas.schuh.84 at gmail.com>
 wrote:

>
> On Jan 23, 2014, at 9:40 AM, Stephen Kelly <steveire at gmail.com> wrote:
>
> > Andreas Schuh wrote:
> >> How often have you seen CMake code as the following
> >>
> >> add_executable(foo foo.cpp)
> >>
> >> ?
> >
> > I see executables with a single source file only in dummy test code, and
> > even then
> >
> > add_executable(foo main.cpp)
> >
> > is more common.
>
> I presume that’s because you mostly worked on larger, mainly C++ or other
> compiled language, based projects. At least in research software you will
> find these quite frequently, where there are dozens of executables
> implemented in single .cpp modules. These may just link to libraries which
> are build from a multiple .cpp modules (that is why obviously add_library
> would not support such short notation), but yet, the executable itself does
> (and IMHO should) only consist of a single .cpp module which defines the
> entry point (main). If you name all these main.cpp, you are not giving away
> what binary file this .cpp module relates to and further have to have them
> all in different subdirectories… Isn’t it nicer to have them all in one
> directory with meaningful names ? I believe program logic should go into
> libraries so it could be reused by other executables or packages if there
> need be.
>

I second this experience, I have worked in a corporate environment and an
academic environment. In the academic environment it is very common for
there to be hundreds small, focused executables and utilities with a single
.cpp file and a number of linked libraries. The corporate environment
preferred their single large executables, though they did have several
utilities as well.

Nonetheless, perhaps this is something better kept in BASIS, but it is
worth consideration for CMake.


>
> >
> >>
> >>>
> >>> Should CMake be extended with similar capabilities somehow?
> >>>
> >>> I personally believe this could be very useful to quite a few users.
> >>>
> >>> Would it help if an IMPORTED executable could be a script?
> >>>
> >>> What would this entail? Is there perhaps another question behind this
> >>> question?
> >
> >> Instead of relying on the actual name of the installed
> >> executable file, the build target is imported and any external
> executables
> >> are only called by their assigned build target name.
> >
> > Yes.
> >
> >>> 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?
> >>>
> >>
> >> The first and foremost target group are clearly research groups
> >
> > Yes.
> >
> >> and less
> >> experienced software developers or those who do not want to bother
> writing
> >> a considerable amount of CMake code rather than their actual software.
> >
> > I'm not personally convinced your approach is the best one, but it's not
> > aimed at me anyway. I'm only interested in finding upstreamable features
> and
> > concepts, and finding gaps in the cmake offering.
>
> We are open to any suggestions for improvements.
>
> The purpose of BASIS is to slim down much of what you can do with
> CMake/CPack/CTest/CDash to what is needed by our target group without
> requiring people to learn every aspect of the yet ever changing “modern
> CMake” approach. Even writing a FindPackage.cmake module is not
> standardized as much as it could be. Defining such standard and offering
> functionality for the most common use cases is what BASIS does. While the
> “modern CMake” may change and needs retraining, BASIS can adapt and use new
> features without changing its user API (as long as possible). This may be
> not what professionals in a software development position prefer, where you
> may have one or two “CMake gurus” who take care of things or you may be one
> yourself, but in less software development oriented environments where
> people write software as a tool to express and experiment with new
> algorithms. For these fellows, whoever develops BASIS is supposed to know
> well about CMake and recent features, utilizing them where needed, and
> transferring their knowledge downstream transparent to the end user (e.g.,
> research developer) via the CMake BASIS package.
>

My hopes differ slightly from Andreas here. In this case I see benefits in
updating the BASIS API (in a non-breaking way) to support more "Modern
CMake" techniques. This is orthogonal to the benefits that can come from
eliminating boilerplate in CMake itself.

Cheers!
Andrew Hundt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140127/23b48ad2/attachment.html>