Open kkaefer opened 8 years ago
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.
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: https://github.com/mapbox/windows-builds/issues/25, https://github.com/mapbox/windows-builds/issues/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 :smirk:.
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 https://github.com/mapbox/mason/pull/465 in the future.
This ticket collects things we want to change about mason in a system redesign:
/usr/local/mason/...
, make them read-only use use the packages from this location.FindPackage
command or another mechanism/cc @springmeyer @TheMarex @artemp @ericfischer @BergWerkGIS