Opened 2 years ago

Last modified 23 months ago

#63960 assigned defect

audacity: strange sdkroot selection

Reported by: jmroot (Joshua Root) Owned by: RJVB (René Bertin)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cooljeanius (Eric Gallager)
Port: audacity

Description

The audacity port contains this:

if {${os.major} >= 17} {
    # Audacity builds "normally" from 10.7 to 10.13, but will request the 10.13 SDK
    # on 10.14 and newer to "prevent high CPU usage and slow drawing". Linking will
    # fail if MacPort lets source be compiled against the platform SDK, so we handle
    # SDK selection ourselves entirely. MP builds aren't required to support anything
    # but the OS version they were built for. On 11.x we just build as if there are
    # no OS specifics.
    if {${os.major} < 20} {
        macosx_deployment_target 10.13
        configure.sdkroot
    }
}

The comment makes it sound like the intent is to build against the 10.13 SDK. But what actually happens is configure.sdkroot is cleared while leaving configure.sdk_version at its default value, which means:

  1. the port will be built against MacOSX.sdk, which will be an indeterminate SDK version, and
  2. a warning will be printed because the requested SDK version is not what ended up in configure.sdkroot.

What is actually intended to happen here?

Change History (4)

comment:1 Changed 2 years ago by RJVB (René Bertin)

What's intended to happen is that the damn thing builds on the 2 CIs and thus presumably on 10.15 and whatever comes after. The build system tries to do something clever (to avoid slow drawing when built against and this plus a patch is what avoids linking errors at the very end.

My various attempts leading to build failures are probably still visible via the PR that led to the port upgrade. I did ask for some assistance figuring this out, got none. Better late than never, but without access to an actual Mac running 10.14 or newer I've decided to be satisfied with this strange result.

Either way, as long as MacPorts doesn't provide the 10.13 SDK one way or another we can't guarantee to build it as intended by upstream, can we?

comment:2 Changed 2 years ago by jmroot (Joshua Root)

Well, there are a few options that would be better than the current situation. In no particular order:

  1. Clear configure.sdk_version as well. That would not change the build but would silence the warning.
  2. Set configure.sdk_version 10.13 and don't clear configure.sdkroot. That will result in the 10.13 SDK being used if available, with MacOSX.sdk being use with a warning printed otherwise.
  3. Just use the default SDK even if newer than 10.13, which is what will usually be happening on 10.14 and 10.15 already (since those systems typically don't have a 10.13 SDK).

comment:3 Changed 2 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:4 Changed 23 months ago by ryandesign (Ryan Carsten Schmidt)

My MacOSX.sdk port (and its subports, one for each major OS version) are now available. If audacity requires an SDK not provided by Xcode or the CLT it could make use of the SDK port. There is not currently any support from MacPorts base or a portgroup to do this so the audacity port would have to make the arrangements manually.

Note: See TracTickets for help on using tickets.