[MacPorts] #52322: New port: depot_tools — a collection of tools for dealing with Chromium development
#52322: New port: depot_tools — a collection of tools for dealing with Chromium development ------------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: depot_tools ------------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/52322> MacPorts <https://www.macports.org/> Ports system for macOS
#52322: New port: depot_tools — a collection of tools for dealing with Chromium development --------------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: depot_tools | --------------------------+-------------------------------- Comment (by william@…): (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!) -- Ticket URL: <https://trac.macports.org/ticket/52322#comment:1> MacPorts <https://www.macports.org/> Ports system for macOS
#52322: New port: depot_tools — a collection of tools for dealing with Chromium development --------------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: depot_tools | --------------------------+-------------------------------- Comment (by william@…): 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 … -- Ticket URL: <https://trac.macports.org/ticket/52322#comment:2> MacPorts <https://www.macports.org/> Ports system for macOS
#52322: New port: depot_tools — a collection of tools for dealing with Chromium development --------------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: submission | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: wontfix | Keywords: Port: depot_tools | --------------------------+-------------------------------- Changes (by mf2k@…): * status: new => closed * resolution: => wontfix -- Ticket URL: <https://trac.macports.org/ticket/52322#comment:3> MacPorts <https://www.macports.org/> Ports system for macOS
participants (1)
-
MacPorts