Uni-branch

[jfirebaugh]

Test build here, triggered locally with ./mason trigger jni.hpp 2.0.0.

It looks as though the triggered build API is rate limited; the responses come back with a "remaining_requests" key that starts with a value of 10 and counts down from there. I got down to 1 before getting everything in order. Haven't seen it reset yet, and can't find documentation about what the timeframe is.

[jfirebaugh]

I think this is ready to go. I've fixed the boost directories and brought over the .travis.yml from each former branch, and the contents are now used for the triggered build.

The remaining question is the discussion in 86dbb40, which let's move here.

@jfirebaugh

Now that we're keeping the scripts in a single branch, we could remove this block and the separate .scripts directory entirely, and use the script file from the local checkout instead. This would improve stability in use cases like mapbox-gl-native. The current behavior can produce broken builds of past revisions, for example during git bisects, when the tip version of some script.sh is incompatible with the version of mason / mason.sh that mapbox-gl-native has pinned. Using mason, mason.sh, and a script.sh all from the same checkout would make that much less likely.

@kkaefer

Hm, that would mean we'd have to re-pin the .mason directory whenever we update a software version?

Overall, our goal for mason is to split the building packages part from the installing/depending on packages part. E.g. I have a sample implementation of a pure CMake-based package installer that integrates into find_library. That also means that we won't have to download a script.sh file anymore because we can directly download the tarball and error if it doesn't exist.

@jfirebaugh

Hm, that would mean we'd have to re-pin the .mason directory whenever we update a software version?

Yes, and that's a good thing. I don't want the build behavior of past revisions of mapbox-gl-native to change when someone modifies a script.sh. For more on this, see #67. The solution I propose there involves adding build revisions to the version number and writing the script.sh to S3. Using script.sh from the local checkout would be a lighter-weight approach that solves most of the same problems. (The part it doesn't solve is prebuilt binaries getting overwritten on S3.)

[jfirebaugh]

Another advantage of using script.sh from the pinned local checkout is it will allow us to be more aggressive about culling obsolete package versions (#60) from mason master without fear of breaking downstream consumers.

[springmeyer]

Using script.sh from the local checkout would be a lighter-weight approach that solves most of the same problems

👍

Another advantage of using script.sh from the pinned local checkout is it will allow us to be more aggressive about culling obsolete package versions (#60) from mason master without fear of breaking downstream consumers.

👍