[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: GSoC 2019 [Phase out dependency on Xcode]
From:       Satryaji Aulia <satraul () gmail ! com>
Date:       2019-03-31 19:37:19
Message-ID: 08DC3606-F37E-41C4-8D9E-A52760BF54F3 () gmail ! com
[Download RAW message or body]

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@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


[prev in list] [next in list] [prev in thread] [next in thread]