[cmake-developers] Modern cross-platform buildsystem design requirements

[Brad King]

On 09/09/2014 06:32 PM, Stephen Kelly wrote:
> I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an 
> attribute to mark an executable specially so that it is built with 
> appropriate flags for the WinRT platform.

Yes.  It is similar to the WIN32_EXECUTABLE target property.

>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728
>  Building executables as libraries (2014-03-21)

FYI, in my Github fork you can see a WIP branch adding support for
NVIDIA's Nsight Tegra Visual Studio Edition.  It links executables
as shared libraries unless they are marked with an ANDROID_GUI target
property.  The property activates creation of a .apk.

> Today, I think 'cross-platform' includes a few mobile platforms as first-
> class targets, and cross-compiling is part of what cross-platform means. So, 
> I wonder what a cross-platform buildsystem necessarily looks like today, and 
> whether it can be done better/abstracted with more first class features.

Good question.  I think support for each mobile target will have to be
added on an incremental basis.  If some common themes emerge over time
then perhaps we can identify some abstractions.  However, each of these
platforms requires some kind of app manifest, and that is a different
file/format for each target platform.  Projects will at least have to
add such manifest files for each platform they want to support.

> I'm reminded of the previous proposal for multiple toolchain use.
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272
> 
> Partly that discussion was aborted because we already had the large topic of 
> designing and implementing usage-requirements to deal with. As that is now 
> complete as designed, it might be worthwhile to re-consider and 
> discuss/design how multiple toolchains could be used at once, whether that 
> would require or benefit from a new language for cmake (another orthogoal 
> known possible future-direction for cmake) etc.

The main challenge here is that CMake exposes a lot of information about
"the one" toolchain per language selected during configuration in the
CMake language as variables.  Your "toolchain scope" proposal would
provide a context for code that will see the toolchain information
for each enabled target toolchain.  However, perhaps it would be better
in the long run to consider something more declarative and with a
new language.

When cross-compiling it is common to build some tools for the host
system to be used during the build itself.  There is always exactly
one host platform, so perhaps we can design a new mode of support for
cross-compiling that configures "the one" toolchain for the *host*
system only.  Then provide some kind of declarative or delayed-until-
generate-time specification, perhaps using a new language, for the
cross-compiled pieces.  Eventually that spec could be used for the
host system too.

-Brad