Mason CMake

[kkaefer]

Following https://github.com/mapbox/mason/issues/187, my long term goal is to split Mason in two pieces: A small-ish client that downloads/installs/uses packages, and a system that builds packages.

We're using the CMake script in gl-native with much success so far; except for a special-case to support old packages, it does not have a dependency on the scripts folder (cf. https://github.com/mapbox/mason/issues/186). Since that is only required for old packages, we don't need it anymore, now that we have newer versions of all packages.

I believe there's value in only having one canonical client rather than several concurrent implementations. Therefore, I'd like to evolve the CMake client and make it the canonical way of using CMake. In gl-native, our build system doesn't require the shell-script based version anymore, but some other supporting scripts still require it, and we use it to install dependencies on CI.

The road forward I am imagining looks like this:

• Add a command mode to mason.cmake by making it executable and adding a shebang of #!/usr/bin/env cmake -P. Instead of adding CMake as a submodule, projects now copy (!) the mason.cmake into their project, and can invoke cmake/mason.cmake install libpng 1.6.20 and similar actions. The only commands we'd need to implement are install, prefix, and possibly cflags, et al.

This leaves out one use case: Installing cross compilers. Right now, we have dedicated support for Android toolchain flags built into Mason. Instead of having it there, I'd like to make this more generic, along the lines of toolchain.cmake/sh (see GCC package). This requires somewhat standardizing the format (/cc @springmeyer @tmpsantos) so that we can switch between compilers more easily.

Another thing to consider when removing the scripts dependency is that we have to manually mark packages as HEADER_ONLY when installing. mason.cmake does this by supporting a syntax like this: mason_use(geometry VERSION 0.9.0 HEADER_ONLY). It might be a good idea to support the same syntax instead of porting over mason.sh syntax: cmake/mason.cmake install geometry VERSION 0.9.0 HEADER_ONLY

[kkaefer]

See https://github.com/mapbox/mapbox-gl-native/blob/remove-mason/cmake/mason.cmake for an altered version of mason.cmake that does this.

Unfortunately, Linux systems can't pass arguments in the shebang, so we'll have to resort to a helper script that just forwards the args and adds -P

[springmeyer]

👍 It feels right to me to be able to use mason packages without the mason bash installation client when appropriate. Thanks for pushing this forward.

I believe there's value in only having one canonical client rather than several concurrent implementations.

The bash client will remain of value however to projects that don't use cmake, right?

[mapsam]

I'm just starting to learn cmake, so pardon if this comment doesn't make a ton of sense!

I'd love to be able to automatically install a common mason.cmake file, like this one - could this live as a template in mason and be added to a project with a (future) Mason client? Something like:

mason init --cmake

Which adds a cmake/mason.cmake file to the project folder.

[springmeyer]

I like how you are thinking here @mapsam. Before I answer specifically I'll sketch out a basic vision for how I think "mason clients" should work.

• We should support 3 official clients:
  • bash, currently in a branch, needs to be finished
  • cmake, currently in the master branch here
  • [nodejs] , needs written: refs #396
• I think it makes sense to move them into separate github repo(s)
  • each mason clients MAJOR version would support the MAJOR version of the "mason build" system (currently we are at 0.x: https://github.com/mapbox/mason/blob/master/mason#L10)
  • any breaking change in the path for packages on S3 would trigger a MAJOR bump
  • When we move on mason v2 (which will involve new S3 urls) you would need to use a v2.x client to be able to opt into downloading packages.

Certainly, once mason.cmake is moved from https://github.com/mapbox/mason/blob/master/mason.cmake to a separate repo is would be easy, for ease of use, to add a command to the nodejs or bash that would init the cmake file. I think your idea of mason init --cmake is great.

Currently users of mason.cmake all copy/vendorize. So I think it would be a non-breaking change to move https://github.com/mapbox/mason/blob/master/mason.cmake to https://github.com/mapbox/mason-cmake or the like. @kkaefer @mapsam - thoughts?