New port: depot_tools — a collection of tools for dealing with Chromium development

[gallafent]

Portfile attached. This is as a move towards being able to build the Dart SDK using MacPorts — its build process relies on these tools.

The portfile unpacks the tools under /opt/local/libexec/depot_tools (as per ​http://dev.chromium.org/developers/how-tos/install-depot-tools the distribution is simply intended to be unpacked and used in-place). Any suggestions for a better place to put it are welcome!

Other ports which use depot_tools to build (i.e. the Dart SDK port I'm having a go at) will use the tools from that location.

I used the date as the version number, since there are no official releases, just a moving-target git repository, and date seemed a good way as any to make a human-readable version number (I pin a specific git commit from that day).

In general these tools update themselves automatically when used. By removing the .git subdirectory, this behaviour should be prevented.

[gallafent]

Portfile for depot_tools

[gallafent]

(Worth holding on before doing anything with this submission … at the moment I'm investigating the reason why the gclient tool decides to install some things in the depot_tools installation prefix. It may be that this stuff is too much of a mess, and the way around it is to make a local depot_tools installation within the working build directory of the Dart SDK in order to use it!)

[gallafent]

OK, I've decided this is a Bad Idea. depot_tools seems frequently to try to add bits of itself when you run commands (gclient), and so having it installed in MacPorts' heirarchy is a no-go since this may (will) happen when a user (or another port being installed) uses those tools.

Furthermore, as per ​https://www.chromium.org/developers/how-tos/get-the-code/working-with-release-branches , it does not seem to be possible, without access to the Google internal document called “go/ChromeReleaseBranches” (or equivalent internal knowledge of the build tools), to create a build tree containing a project which is managed by depot_tools and which matches a specific release tag of a product. Since my motivation for doing this was to get a build from source of the Dart SDK (Version 1.19.1 at the time of writing) from a specific release tag, in order to have a fixed version of the port available in MacPorts (as requested in #51751), there's no longer any purpose in this proposed depot_tools port, so please simply close this ticket! The only way this is likely to happen is if somebody at Google decides it's a good idea and provides a portfile encapsulating the secret knowledge regarding how to build a Dart SDK from a release tag, and the impression I have of that is that it's unlikely: for better or worse they have decided to make Dart a brew exclusive (as per ​https://plus.google.com/+dartlang/posts/WX47S62PjBs ). Of course, the brew installation just uses the prebuilt SDKs rather than building on the host Mac, as per ​https://github.com/dart-lang/homebrew-dart/blob/master/dart.rb …