[pull] master from Carthage:master #322
Open
+2,202
−1,519
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Co-authored-by: Jonathan Bachmann <[email protected]>
* Update README guide for Xcode 11 changes * Add Xcode 10 and lower instructions
If you’re looking for the canonical v0.34.0, see <25ad8c8ed7>. Carthage will have a version bump again for the actual next release. This just elides a potential «Please update to the latest Carthage version» message for invocations of an executable that’s build off master branch and the like.
Newer versions of Xcode don't have an iPhone 6s by default so this should be a good compromise that works on older and newer versions of Xcode.
…-directory» flag to function. (#2980) Also, sanitize [nul characters](https://en.wikipedia.org/wiki/Null_character) in `GitURL`s (transposing them to «␀».) The cases in the modified test are — given a URL is specified and provided is a string without URL scheme — pathological, and as such the result for them from `GitURL.name` are maybe unintuitive, but decidedly safe. The flag «--project-directory» clashed with the formerly placed (but never shipped in a tagged Carthage release) invocation of `FileManager.currentDirectoryPath`. To avoid the clash, we settle on a less intuitive, but most importantly safe change — _to be clear_ a *breaking change* for some pathological URL-scheme–less or nul-character–containing Cartfile lines and `GitURL`s.
See <f656edfe35651b54eec50d814e79d079f8eea7c4>. Sanitizes «...git» in addition to other sanitization. Adds unit and integration test.
PRs «Fix fetching race condition (#2832)» and «Improve submodule performance when --use-submodules is not used (#2795)» provide benefits, but also major risk of cache clashes in the vein of <github.com//issues/569>. Basically, submodules before those two PRs had their bare git repos cached in way dissimilar to `~/Library/Caches/org.carthage.CarthageKit/dependencies` — that is they’re either “cached” how a git submodule init/fetch stores them or re-clone from remote with the subsequent checkout following a removal of the worktree. This regression slipped past our unit (and small number of integration) tests. And, upon further testing out of popular frameworks in combination, caused major issues. Follow up revert of associated commit <68abf2d73791720457f5be1aab4b57df86483f88> incoming. This reverts commit 55e416a.
…ed (#2795)" PRs «Fix fetching race condition (#2832)» and «Improve submodule performance when --use-submodules is not used (#2795)» provide benefits, but also major risk of cache clashes in the vein of <github.com//issues/569>. Basically, submodules before those two PRs had their bare git repos cached in way dissimilar to `~/Library/Caches/org.carthage.CarthageKit/dependencies` — that is they’re either “cached” how a git submodule init/fetch stores them or re-clone from remote with the subsequent checkout following a removal of the worktree. This regression slipped past our unit (and small number of integration) tests. And, upon further testing out of popular frameworks in combination, caused major issues. This reverts commit 68abf2d.
…ng, and `objdump` flag unavailability under Xcode 7.X.
…om `xcodebuild -showsdks -json`. Previously, Carthage would propagate errors upon reading non-compiled-in values from `SUPPORTED_PLATFORMS` or `PLATFORM_NAME`. Carthage’s `--platform` argument takes the same input of 2019-era SDKs — however, in alignment with the above: the default (a.k.a. “all”) parameter will allow dynamically-parsed SDKs to propagate. CarthageKit’s `BuildOptions.platforms` provides even more control — now, takes a true set of dynamically-parsed SDKs where empty set means empty set, and `nil` means use various default values. Eliminate usage of `XCDBLD.Platform` — we were using Platform wrong, twisting it into a simulatorless instance of the SDK. • instead, we just derive a method for that — `SDK.platformSimulatorlessFromHeuristic` • all the info needed for that gets parsed from -showsdks -json and stored in the SDK type `carthage archive` still uses the hardcoded four 2019-era SDKs. The `carthage cleanup` command — existing on-master, but unshipped-in-tags — no longer makes sense (when set of SDKs are non-fixed across Xcode versions.) • The crucial function `removeUnneededItems` now functionlessly returns an empty signal. • That function and the entire command will be removed in a subsequent commit. • Again, to note once more, this command never shipped in a tagged Carthage release. The previous hardcoded `XCDBLD.SDK` remains for illustrative effect (renamed to `XCDBLD.SD_K`) and will be removed in a subsequent commit. Dynamic SDK parsing can occur from `xcodebuild -showsdks -json` with fallbacks to `BuildSetting` extraction from a Xcode-bundled `xcodeproj`, beyond falling back to hardcoded 2019-era values. Will omit SDKs — such as DriverKit — where JSON-derived `canonicalName` and `platform` do not share a common prefix · DriverKit has an ouptut `canonicalName` similar to «driverkit.macosx19.0».
…-in-tags — which no longer makes sense (when set of SDKs are non-fixed across Xcode versions.) See also <github.com//pull/2872> — and major thanks to @sidepelican and @chuganzy for developing it… 〜 sorry that the new system of dynamically parsed SDKs makes it nonviable; maybe it's viable in some future way… See commit 883f1c8.
…c SDK enum. The non-dynamic SDK enum has replacement in commit 883f1c8. Eliminate declaration of `XCDBLD.Platform` — we were using Platform wrong, twisting it into a simulatorless instance of the SDK. • instead, we just derive a method for that — `SDK.platformSimulatorlessFromHeuristic` • all the info needed for that gets parsed from -showsdks -json and stored in the SDK type See `SDK.platformSimulatorlessFromHeuristic` from commit 883f1c8.
…global (via static nature) variable initializer.
Error looked like:
```
/Users/crusty/Projects/Xcode/Carthage/Source/XCDBLD/SDK.swift:80:3: error: call can throw, but errors cannot be thrown out of a global variable initializer
KeyValuePairs.reduce([
^
```
Co-authored-by: J.D. Healy <[email protected]>
…mostly for reason of cross–file-system-device dangers. • Also, seems likely that all versions of `lipo` in Xcode versions that Carthage supports can now handle multiple `-remove` flags. • A subsequent commit will aim that at reducing the same ‘there is a concurrency issue’ multiple-«copy-framework»-running-simultaneously read/write issue. ``` git revert --no-commit e80d670 b465ba1 a90f851 a217a58 2d066f0 e30998c e43ad4d 80fe44d 0acf9e1 ```
…ure stripping, lessening multiple-«copy-framework»-running-simultaneously read/write issue. • Add nondestructive strip architectures CarthageKit function. • Add private `architecturesInPackage` with return type `Value` of `[String]` • Differentiable from the public `architecturesInPackage`, by having an added `xcrunQuery` parameter. • Add preferred `copyAndStripFrameworks` function and use in «copy-frameworks». • Keeps around `stripFramework(_:keepingArchitectures:strippingDebugSymbols:codesigningIdentity:)` to not depreciate any public API.
* Fix spelling * Fix spelling fix
* Fix usage of PREFIX for installed binaries.
PREFIX was not honoured before in BINARIES_FOLDER and there were
several places where the path has been reconstructed in place of
using just the BINARIES_FOLDER variable
* Makefile: disable sudo on SUDO=false
In order to perform unprivileged installs allow disabling sudo using
$ make install DISABLE_SUDO=1
This allows installing to another prefix without using sudo, e.g.
$ make install PREFIX=/opt/local DISABLE_SUDO=1
#3025) FileManager.replaceItem(_:withItemAt:backupItemName:options:) does not work if the source and destination are on the same filesystem.
* Adds support for no_proxy/NO_PROXY * Makes sure that downloaded binaries use proxied environment
Fix typo in fileReadCorruptFile error description
README.md: HTTP => HTTPS
Fit Xcode 13, #3201
* Use modern Alamofire version in README. * Use Alamofire 5.5 example.
… is disabled in Xcode 14
Fix issue where Carthage doesn’t build for watchOS or tvOS if bitcode is disabled in Xcode 14
Bump up version to 0.39.0
…ive changes to XCBLD’s SDK. • Move `selectAvailableSimulator` to a new query method `sdk.simulatorJsonKeyUnderDevicesDictQuery` • Add knownIn2023Year APIs. • Fix some whitespace that had spaces in a tabs-based file.
…inker is `xcrun --find ld` returned. If the new linker is there, then `dirname $(xcrun --find swift))/../lib/swift_static/macosx` should not be respected as the sentinel value it held in pre-«Xcode 15» days. In the Makefile, we look for `'^only one snapshot supported'` (which only exists in the old linker) to tell us the old linker is present. See <https://github.com/apple-opensource/ld64/blame/8568ce3517546665f1f9e0f7ba1858889a305454/src/ld/Snapshot.cpp> for the old linker. See <https://github.com/apple-oss-distributions/dyld/> for the new linker. Closes <#3348>.
…CarthageKitTests».
Minor note: nothing about the 'MKDIR=mkdir -p' line was wrong — we're just doing a more verbose thing everywhere that variable was previously used. This is just based on a maintainer (me) spotting this and desiring the Makefile to be hardened. Nothing concrete led to this.
…iable — to use square brackets instead of an emoji. This will make the test behave correctly on newer Foundation versions.
…some ProjectSpec tasks. Verified it compiles on Xcode 11.3.1 nicely. Untested at runtime. Best effort.
…hould not locate the project from a directory not containing it"`.
…ACKAGE` ones which are conditionalized as such because the fixtures for those don’t exist as `.frameworks` in their prior location when we made the years-ago switch to building with Swift Package Manager.
…ed by "should build for platform […] in total" case. That test had a title of "should build all subprojects for all platforms by default". See subsequent commit for the superseding test case.
…leSubprojects` and away from `carthage-fixtures-ReactiveCocoaLayout-master`. Do some file replacement in that `dir` on `beforeEach` of `XcodeSpec`. Rename the three affected tests and make code less duplicated. Rename and buff up two tests which now find workspaces. Recent Xcodes would fail to compile one or more of the projects of "carthage-fixtures-ReactiveCocoaLayout-master". Remove comment "[t]he fixture is maintained at https://github.com/ikesyo/carthage-fixtures-ReactiveCocoaLayout" as we now use another (already-existing in github.com/carthage/carthage) fixture. Three renamed tests now have names like "should build [solely] platform […] in total" instead of "should build for all platforms." Two other tests are renamed: "should locate the project" → "should locate the workspace" and same for "from the parent directory." 〰️ A single new expectation is added to each of these that provides more elaboration due to limited debugDescription of `ProjectLocator`. 〰️ But expectations don’t short circuit, so the existing ‘last expectation’ will still always run. Use `apple archive` (with CLI `aa`) to do file replacement in the `beforeEach` of `XcodeSpec`. Copy `SampleMultipleSubprojects` an additional time in `copy-fixures` shell script (to `"$destination/SampleMultipleSubprojectsSameOldSameOld"`.)
…`.travis.yml` no longer launches any Travis runs. With Travis' macOS specifics in the following link, our `.travis.yml` no longer launches any Travis runs: https://www.travis-ci.com/blog/2020-11-02-travis-ci-new-billing/ For our future use on other CI platforms, I've included `for_use_during_unit_testing_for_carthage_on_intel_host_os.xcconfig` scripting.
…ile (`carthage`) after copy-paste carryover blip that never shipped. This was spotted in the PR review stage.
Signed-off-by: RoboSchmied <[email protected]>
…ix `-showBuildSettings` with solely the `archive` action. No longer (under Xcode 16 and above) leave `OBJROOT` as stands. Deal with error ‘Found no destinations for the scheme [^\n]+ and action[…]’. No longer (under Xcode 16 and above) prefix `-showBuildSettings` with solely the `archive` action. Carthage has long-standingly built `simulator` code under the `build` action, but (due to certain now-believed-to-be-fixed bugs, had historically passed the `archive` action when querying under simulator destinations for Xcode Build Settings.) Such a ‘discrepancy which Carthage relies upon improper values out of alignment with Xcode action verb,’ we now believe no longer works around any bugs and Xcode 16 (beta 1 (16A5171c) at the very least) now returns ‘proper’ Build Settings for simulator destinations and the `archive` action. Xcode Build Setting `OBJROOT` now appears to have more path components. We lop some off (only under Xcode 16 and above.) Out of the three here, Carthage authors are most unsure about leaving this code change ‘as it stands.’ Especially under the purview of Carthage setting `--derived-data`. I’ll comment in the below link as actually running Carthages tests (unit and integration) should ‘prove out’ its sufficiency or deficit. PRs welcome. Under all Xcode versions, all xcodebuild invocations of `-showBuildSettings` that return non-0 exit code and standardError matching `error[:] Found no destinations for the scheme [^\n]+ and action [^\n]+[.]\n` will see non-surfacing of those errors. Carthage proceeds as if that xcodebuild invocation never happened (which is essentially how Carthage behaved before it had one more non-0 exit code return to deal with.) `brew install carthage --head` is a pathway that exists (attempt at one’s own discretion, and use the internet for associated prerun commands such as `brew uninstall` and others.) 〜 As several CI providers no longer provide both ‘VNC access’ and Intel Mac builders, Carthage currently has no CI. Carthage maintainers shall be fixing this and commenting in the below link (and elsewhere.) Potentially fïxes #3375. Potentially fïxes #3374. See #3374 for future updates on sufficiency of this commit, and whether lack of ‘may be reverted’ stands.
…d` — have Carthage pass `SUPPORTS_MACCATALYST=NO` just before `CARTHAGE=YES`. I would wager (even though Carthage can and will fix this easily) Apple may eventually deem this their Xcode Build Settings bug and fix this in a further Xcode 16 beta. The Build Setting under question is `EFFECTIVE_PLATFORM_NAME` containing `-maccatalyst` in an invocation like `xcodebuild -project "/private/var/tmp/Alamofire5•9•1•••Carthage/Carthage/Checkouts/Alamofire/Alamofire.xcodeproj" -scheme "Alamofire iOS" -configuration Release CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES build -showBuildSettings -skipUnavailableActions`. We can fix this by — just prior to `CARTHAGE=YES` additionally having Carthage pass `SUPPORTS_MACCATALYST=NO` — which doesn't speak ‘universal truth’ about the framework we query, but does speak truth about how Carthage handles any framework or library. (Carthage always handle frameworks or libraries without attempting any maccatalyst builds.) We consider adding that passed/hardcoded build setting safe — considering any likelihood ‘build setting chaining/interpolation’ using `SUPPORTS_MACCATALYST` is guessed to be almost entirely non-existent. But please chime in if unexpected downstream effects are seen (and file a new bug detailing which framework.) If Apple fixes this in a further Xcode 16 beta, we may revert this. `brew uninstall carthage; brew install carthage --head` is a pathway that exists (attempt at one’s own discretion, and use the internet for associated prerun commands such as `brew uninstall` and others.) 〜 As several CI providers no longer provide both ‘VNC access’ and Intel Mac builders, Carthage currently has no CI. Carthage maintainers shall be fixing this and commenting in the below link (and elsewhere.) Fixes #3376.
…ttern to permit more before “Found” and after “error” (due to Xcode 16 Beta 6 and beyond.) (#3381) * Update pattern to match error message for skipping build settings read * Change pattern to match messages in previous Xcode versions
Commits «9e2006a», «cf06392», and «87fedfb» were tested on a local machine running macOS 12.7.6 21H1320 Intel inside VMWare Fusion using Xcode 14.2 with all simulators installed. All relevant tests passed. Integration tests were not attempted (but those are not relevant under Xcode 14.2) but may be attempted later. For Swift Package Manager-driven tests, all relevant tests passed. Some by-hand testing occurred using Xcode 16 betas (multiple of them) under macOS Sonoma on an Apple silicon machine with various sets of simulators installed. See #3374 for the state of running Carthage’s tests on Apple silicon — and why by-hand testing was necessary. See #3374 for details on the relevant tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )