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 > On Mar 29, 2019, at 1:35 AM, Satryaji Aulia <[email protected]> wrote: > > Hi Marcus, I’m a final-year student from University of Indonesia interested > in contributing to MacPort, and I’m working on my proposal right now. > > I’d like to ask about the Phase out dependency on Xcode project idea on the > Wiki page. > > Just making sure of the flow: user/maintainer installs a Port using trace > mode (-t), if it turns out it the Port needs the full Xcode package, it > outputs: > - An error message if full Xcode is not installed. > - A warning message if use_xcode yes in the Portfile is not set. > Thus, all the contributions are to be made on the macports-base repo. Correct? > > In achieving this, exactly which parts of the codebase need to be modified > and how do you detect that a package needs full Xcode? > > I understand that trace mode reads filenames that are accessed using > DYLD_INSERT_LIBRARIES. Do we compare these filenames to a list of filenames > that are from the full Xcode? > > Looking forward to your reply. > satraul
