ld64: default to +ld64_xcode on Xcode9+

[kencu]

ld64 does not understand tapi in the open-source
versions at present.

I believe that XCode 9+ generates the tapi lookups -- open to fine-tuning of the details on this.

closes: https://trac.macports.org/ticket/56843
closes: https://trac.macports.org/ticket/53784
closes: https://trac.macports.org/ticket/56398
closes: https://trac.macports.org/ticket/56277
see: https://trac.macports.org/ticket/56647
see: https://trac.macports.org/ticket/54510
see: https://trac.macports.org/ticket/54506
see: https://trac.macports.org/ticket/53151

[macportsbot]

Notifying maintainers:
@jeremyhu for port ld64.

[macportsbot]

Travis Build #2977 Errored.

Lint results

--->  Verifying Portfile for ld64
--->  0 errors and 0 warnings found.

Port ld64 success on xcode9.4. Log
Port ld64-97 fail on xcode9.4. Log
Port ld64-127 success on xcode9.4. Log
Port ld64-136 fail on xcode9.4. Log
Port ld64-236 success on xcode9.4. Log
Port ld64 success on xcode8.3. Log
Port ld64-97 fail on xcode8.3. Log
Port ld64-127 success on xcode8.3. Log
Port ld64-136 fail on xcode8.3. Log
Port ld64-236 success on xcode8.3. Log
Port ld64-latest success on xcode8.3. Log
Port ld64-xcode success on xcode8.3. Log
Port ld64 success on xcode7.3. Log
Port ld64-97 fail on xcode7.3. Log
Port ld64-127 success on xcode7.3. Log
Port ld64-136 fail on xcode7.3. Log
Port ld64-236 success on xcode7.3. Log
Port ld64-latest success on xcode7.3. Log
Port ld64-xcode success on xcode7.3. Log

[cjones051073]

So this has hit the maintainer timeout.

Given it fixes a number of issues, and I can attest to it in as far as I have been using the variant in another context and not seen any issues so far, I would suggest we go ahead and merge. ?

[mf2k]

I concur, let's push this. Any objections?

[kencu]

pushing it won't break anything, I think. We may find the xcode test needs a bit more tweaking, but we can sort that out as we go. Jeremy is clearly super-busy these days. I don't think he'd mind a small change like this...

[pmetzger]

Given the consensus, I will do the merge.

[ryandesign]

Note that increasing the revision of ld64 was pointless and just forced everyone who already had ld64 installed to rebuild it. The port always ensures that one of its variants is set, and rebuilding it would not cause this new variant to become selected; MacPorts preserves variant selections on upgrades.

Note that this port has subports, and it's generally not a good idea to specify the revision globally in such ports. Most of the subports already set their own revision, but ld64-xcode did not, so setting the global revision increased the revision of the ld64-xcode subport unnecessarily, though nothing about it has changed, causing another unnecessary rebuild.

Of course you can't decrease the revision now that it's been committed, but moving the revision 1 line to both the subport ld64-xcode block and the if {${subport} eq ${name}} block would increase clarity.

[kencu]

most people would have had it installed with no variant set, I thought.

bumping the rev was meant to force to xcode variant to install on the specified systems....

did it not work that way? If not, how should we fix it to do so?

[cjones051073]

I thought the same which is why I also rev'bumped cctools when I committed a similar patch.

@ryandesign I just did a test and if previously the user had no variants selected, which is the case at least on macOS10.13, then the rev bump seems to have had the intended affect.

What I tried was to replace the update here. So I first force uninstalled the ld64 port, and then hacked the Portfile to revert the changes here. I then installed it as per defaults

 > sudo port install ld64
--->  Computing dependencies for ld64
--->  Fetching archive for ld64
--->  Attempting to fetch ld64-3_0.darwin_17.x86_64.tbz2 from https://packages.macports.org/ld64
--->  Attempting to fetch ld64-3_0.darwin_17.x86_64.tbz2.rmd160 from https://packages.macports.org/ld64
--->  Installing ld64 @3_0
--->  Activating ld64 @3_0
--->  Cleaning ld64
--->  Updating database of binaries
--->  Updating database of C++ stdlib usage
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.

Note no variants were previously default selected here.

I then updated the port file, adding back the changes here, and ran a normal update.

 > sudo port upgrade outdated
--->  Computing dependencies for ld64
--->  Fetching archive for ld64
--->  Attempting to fetch ld64-3_1+ld64_xcode.darwin_17.x86_64.tbz2 from https://packages.macports.org/ld64
--->  Attempting to fetch ld64-3_1+ld64_xcode.darwin_17.x86_64.tbz2.rmd160 from https://packages.macports.org/ld64
--->  Installing ld64 @3_1+ld64_xcode
--->  Cleaning ld64
--->  Computing dependencies for ld64
--->  Deactivating ld64 @3_0
--->  Cleaning ld64
--->  Activating ld64 @3_1+ld64_xcode
--->  Cleaning ld64
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

 > sudo port installed ld64
The following ports are currently installed:
  ld64 @3_0
  ld64 @3_1+ld64_xcode (active)

So now I have it installed and active with the Xcode variant selected.

[ryandesign]

most people would have had it installed with no variant set, I thought.

bumping the rev was meant to force to xcode variant to install on the specified systems....

Oh. My apologies, you're right. I thought a variant was always selected for ld64, but it looks like for "latest" that wasn't the case, so increasing the revision does indeed help here. Still, the revision increase for the ld64-xcode subport was unnecessary, and the revision lines should be move to each subport that they affect.

I thought the same which is why I also rev'bumped cctools when I committed a similar patch.

For cctools, it is as I said: a variant was already always selected, therefore revbumping there wasn't helpful. MacPorts base doesn't offer a supported way of forcing a variant to be deselected during an upgrade, which is what would be required in order for cctools to automatically give upgrading users the xcode variant there. Such a feat was recently attempted for another port in bed79e2. The solution employed there is not working on the buildbot (see ticket 56778) but that may be due to an mpbb bug so it might be ok to use a similar method on cctools.

[cjones051073]

Yes, of course, for cctools it didn't do what I wanted. Lucky for that port the issues with Xcode 9 are currently much more limited than they where for ld64 (the update was in fact mostly to future proof the port for the next OS). So I am not sure its worth the effect to try what you suggest above.