GSoC 2019 [Phase out dependency on Xcode]

Satryaji Aulia satraul at gmail.com
Sun Mar 31 19:37:19 UTC 2019


Thank you Mojca and Marcus for the response.

It's totally okay to risk scaring me off! I'd ultimately like to contribute so I like the honest feedback haha. I'd like to report/ask about several things:

- Xcode detection

The detailed explanation is helpful and it clarifies a lot. So to me it seems like the core solution of the problem is simple but the extended functionality (trace mode) is a bit more complex. I'll research more about trace mode and get back ASAP. If it seems difficult, I'll put Xcode detection for stretch goals and assign my schedule with more doable tasks. Would you advise doing that, or do you think it's mandatory for this project idea?

- The "port bump" tool

I did `port livecheck maintainer:nomaintainer` for several minutes and updated some Ports [1][2], one which I have used before (chromedriver) [3]. I notice how useful a "port bump" command would be if it existed. I will work on this feature right now. Hopefully I can make a functioning tool by the end of the week. I will add the extended implementation to my proposal.

- Ports which depend on obsolete Ports

A Port that need updating [4] depend on php5-web, but still depends on php5 (obsolete, successed by php53). The non-destructive solution would be to replace php5-web with a new app called php53-web I guess. Also, the ruby port is Ruby 1.8.7, which has been long retired since 2013 and all rb-* gems depend on it. It seems that people still use this version and some of the gems could be updated [5]. What's the stance about supporting retired versions?

I will get back with an updated proposal soon, which will be better. Thank you for reading.

[1] https://github.com/macports/macports-ports/pull/3978
[2] https://github.com/macports/macports-ports/pull/3977
[3] https://github.com/macports/macports-ports/pull/3974
[4] https://trac.macports.org/ticket/58173
[5] https://trac.macports.org/ticket/55974

> On 31 Mar 2019, at 03.55, Marcus Calhoun-Lopez <mcalhoun at macports.org> wrote:
> 
> Greetings.
> 
> Forgive me if this is obvious to you, but just to make sure we are on the same page, I will go into a little more detail than you probably want.
> The first thing to understand is that adding support for `use_xcode` (and/or `use_command_line_tools`) is the *first step*.
> This should be fairly easy.
> After that, you would modify trace mode to assist maintainers in figuring out if changing `use_xcode` is *necessary*.
> Trace mode is the part of the base code I am least familiar with, but I believe this is a reasonable goal.
> 
> Currently, the official policy is that MacPorts requires *both* Xcode and the command line tools need to be installed [1].
> The `port` command issues warnings if either one is not installed [2].
> That being said, several (many?, most?) ports build fine with just the command line tools.
> There are at least a few ports that would build just fine with just Xcode (e.g. port that build with qmake [3]).
> In a Portfile, if `use_xcode` were set to `no`, MacPorts would have to attempt to build the port with just the command line tools.
> Just to be clear, `use_xcode` does not exist yet.
> MacPorts does have *some* support for systems without Xcode, but the code is new, untested, and has not even made it into a released version of MacPorts [4].
> 
> After `use_xcode` is implemented, the next step would be to help maintainers determine if they should change it in a Portfile.
> With my somewhat limited understating of trace mode, you might want to start with porttrace.tcl [5].
> For example, if `use_xcode` is `no`, then some of the directories being added to the sandbox no longer make sense.
> 
> Here is the flow we have now:
> A user installs a port.
> If Xcode is not installed, a warning is issued, and maybe the port installs and maybe it doesn’t.
> 
> Here is the flow we would like:
> A user installs a port.
> If, in the Portfile, it is explicitly stated that Xcode is not needed, then Xcode is not used, regardless of whether it is installed or not [6].
> The port builds successfully.
> To facilitate the flow we would like, trace mode attempts to determine if Xcode is being accessed and used, which would be strong indicator that Xcode is needed.
> 
> If I have not satisfactorily answered your question, please feel free to ask for clarification.
> 
> -Marcus
> 
> [1] https://www.macports.org/install.php
> [2] https://github.com/macports/macports-base/blob/45e62d7e9e7679a43075d1912c8d4a06c2abc6fe/src/port1.0/portutil.tcl#L3296
> [3] https://doc.qt.io/qt-5/qmake-manual.html
> [4] https://github.com/macports/macports-base/commit/76a804cc360924927fa8e2dfa41c761a19d17f3b#diff-98449d939df165f9b8cc4d1aab90ed2c
> [5] https://github.com/macports/macports-base/blob/master/src/port1.0/porttrace.tcl
> [6] https://trac.macports.org/wiki/ReproducibleBuilds


More information about the macports-dev mailing list