Opened 5 years ago

Closed 5 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)

Portfile (1.6 KB) - added by gallafent 5 years ago.
Portfile for depot_tools

Download all attachments as: .zip

Change History (4)

Changed 5 years ago by gallafent

Attachment: Portfile added

Portfile for depot_tools

comment:1 Changed 5 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 5 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 5 years ago by mf2k (Frank Schima)

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.