Hi all,
We've solved all known existing problems in macports-base master
relating to the Xcode changes.
1. Ports use Xcode's SDK when we want to prefer CLT instead
We now check first for CLT SDKs if port isn't Xcode-dependent. CLT
SDKs for macOS mirror the ones shipped with Xcode.
2. Ports in
Hi,
On Wed, Jul 17, 2019 at 01:03:26PM +0700, Satryaji Aulia wrote:
> There’s no existing code in port 1.0 that accesses a PortGroup
> (besides lint which parses the file) so I assume that change needs to
> be for macports-ports right? When do we make this change?
Correct. We can make the change
Hi,
Clemens Lang wrote:
As a consequence I would say that the xcodeversion PortGroup should set
use_xcode yes.
There’s no existing code in port 1.0 that accesses a PortGroup (besides
lint which parses the file) so I assume that change needs to be for
macports-ports right? When do we
Hi Sat,
On Tue, Jul 16, 2019 at 10:57:41PM +0700, Satryaji Aulia wrote:
> We haven't discussed whether or not the `xcodeversion` PortGroup
> should be included. We also **restrict** Xcode in tracemode if not
> needed. An exception if is CLT isn't installed.
The xcodeversion PortGroup says it
To say it more explicitly:
Besides removing the messages revolving Xcode, the latest changes in
macports-base now **force** MacPorts to use CommandLineTools instead
of Xcode.app for common tools like make, clang etc. This is to make every
build reproducible and force ports to explicitly declare
To update from last month about phasing out Xcode,
1. What has changed from last time
The warnings that Xcode should be installed has been removed.
DEVELOPER_DIR is now universally exported for every command (build,
destroot, autotools, etc.).
2. The effects of the changes
Right now, we’re
Hi all,
I'd like to write about what we've accomplished so far in this project,
with my mentors Marcus (mcalhoun) and Clemens (cal/neverpanic).
The project's focus is to provide a smoother experience of using MacPorts
without Xcode.
1. Opened PR for better handling of Xcode dependency [1]
