Opened 8 years ago
Closed 8 years ago
#52322 closed submission (wontfix)
New port: depot_tools — a collection of tools for dealing with Chromium development
Reported by: | gallafent | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | Cc: | ||
Port: | depot_tools |
Description
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.
Attachments (1)
Change History (4)
Changed 8 years ago by gallafent
comment:1 Changed 8 years ago by 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!)
comment:2 Changed 8 years ago by 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 …
comment:3 Changed 8 years ago by mf2k (Frank Schima)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Portfile for depot_tools