Mason wishlist

[kkaefer]

This ticket collects things we want to change about mason in a system redesign:

• Split building packages from using them: There should be two parts of the system, one that knows how to build a package, and the other how to use them. The latter is ideally very small/lightweight. Allow mason install to work without scripts? #186 Include configuration variables in package #176
• Cross compiler installation: We want to be able to install Mason packages that contain a cross-compiler (e.g. for Android, or upgrading Clang on Travis). In that case, the cross compiler needs a standard way to supply all of the environment variables.
• Share packages system-wide: Some packages are very large, e.g. compilers with their associated sysroot, so having them installed into every project fills up the disk pretty fast. Instead, we could install them into /usr/local/mason/..., make them read-only use use the packages from this
  location.
• Support for multiple C++ ABIs: Our C++ packages can be compiled against multiple ABIs, and they're incompatible. Packages that expose a C++ interface (e.g. Boost, GeoJSON-VT) should include the stdlib version slug in their package version name.
• Debug vs. Release packages: Sometimes it's useful to have the debug version of a package. Put -DNDEBUG in compile flags #126
• CMake integration: It should be easy to use Mason packages with CMake, e.g. with the FindPackage command or another mechanism
• Upload packages to other locations: We currently upload everything to an S3 bucket we control, but ideally that would be configurable, so we could e.g. upload packages to GitHub or BinTray.
• Sign/validate packages: We should support signatures and validation to ensure package integrity.
• Windows support: Do we need it?

/cc @springmeyer @TheMarex @artemp @ericfischer @BergWerkGIS

[brunoabinader]

Good insight @kkaefer - deploying files into /usr/local usually requires sudo privileges. For scenarios where sudo privileges are not an option, we can fallback to something like e.g. ~/.mason. We could handle that with an environment variable similar to PATH - e.g. MASON_PATH - that could contain all these lookup paths separated by colon.

[wilhelmberg]

Windows support: Do we need it?

windows-builds is more or less a rough equivalent of mason, although mainly targeted to building mapnik and its dependencies.
It's a huge convolution of batch files and (dirty) hacks to get things building as Windows support is unfortunately still poor for some dependencies.

Porting to mason has been a long standing issue: mapbox/windows-builds#25, mapbox/windows-builds#59

I already started to implement new build scripts (mapnik-gyp/new-win-build-scripts, mapnik/new-win-build-scripts, windows-builds/build.csx), but they don't take a mason-like approach.

Would really love some feedback how the mason approach has worked out so far and if I should reevaluate my approach to new-win-build-scripts as I badly want to get rid of the BAT files as they've been responsible for most of my hair loss 😏.

[springmeyer]

We should create per-arch build dirs so that we can run config from scratch instead of relying on the build system to update it correctly

Noting this to avoid #465 in the future.