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

[Stephen Kelly]

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.

> 
> The basis_add_executable supports this use case as well, but additionally
> the shorter notation (not counting the basis_ prefix ;) )
> 
> basis_add_executable(foo.cpp)

Yes, that's what I was referring to. I see why you have it. I'm not 
convinced it should be upstreamed.

> is intended to bridge both, make the use of
> globbing expressions convenient and safe at the same time.

I would like to see investigation into what can be done upstream to benefit 
cmake users who do not use BASIS.

>> Another example: You have code for adding scripts as executables. What
>> are the generic (non-BASIS related) use cases for that?
>> 
> You can define dependencies among them or to modules written in the same
> scripting language. 

Can you say why this is useful? 

Is it only useful in cases where the buildsystem creates a 
particular/modified script from an input, such as by replacing @VAR@? 

> You can have find_package calls to find installed
> modules and declare that your script depends on them.

Why is this useful? If my script depends on something external I require the 
find_package. Can you be more specific on what BASIS does in addition here?

> An installation rule
> for the script may ensure that the modules get installed as well. 

I can imagine that defining, say, a python library as such for packaging and 
installation purposes could be generically useful, but I'm not sure that 
that is what you are saying. I'm trying to find descriptions of things in 
BASIS that should be in cmake, that show gaps in cmake functionality etc.

> When
> wrapping scripts in Windows Command files to mimic the she-bang directive
> of Unix, calling such script becomes just as convenient as it is on Unix
> from the command line without having to specify the interpreter executable
> explicitly.

I'm not familiar with Windows, but this comment doesn't seem to relate to 
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.

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

> Initially I started off overriding the original CMake commands

Yeah, don't do that... :)

> On a side note, just today a co-worker asked me why the compiler cannot
> find the header files when they were provided as additional arguments to
> the add_executable command. Indeed this was a reasonable assumption, I
> think. Why the need for an additional include_directories when I already
> specified where the header files are located ? This is not something BASIS
> is taking care of yet either, but would certainly be one of the things I
> would consider adding.

This is the kind of concrete feedback *about cmake* that I'm looking for in 
this discussion. It's self contained, refers to existing cmake 
functionality, it's easy to imagine the 'user story' and what the user code 
would look like etc.

I don't have any comment about the viability of adding such functionality to 
cmake add_* commands though.

Thanks,

Steve.