Skip to content

rsync on macOS does not support the --ignore-missing-args option #181

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
euanh opened this issue Feb 13, 2025 · 2 comments · Fixed by #184
Closed

rsync on macOS does not support the --ignore-missing-args option #181

euanh opened this issue Feb 13, 2025 · 2 comments · Fixed by #184
Labels
bug Something isn't working

Comments

@euanh
Copy link
Contributor

euanh commented Feb 13, 2025

#170 added the --ignore-missing-args flags to the rsync command. Unfortunately the version of rsync provided by current versions of macOS (15.3) does not support this flag:

[23/23] Applying swift-sdk-generator
Build of product 'swift-sdk-generator' complete! (5.63s)
2025-02-13T14:01:38+0000 info org.swift.swift-sdk-generator : packageCount=11 [SwiftSDKGenerator] Downloading Ubuntu packages...
2025-02-13T14:01:39+0000 info org.swift.swift-sdk-generator : [SwiftSDKGenerator] Unpacking Swift distribution for the target triple...
2025-02-13T14:01:42+0000 info org.swift.swift-sdk-generator : [SwiftSDKGenerator] Copying Swift core libraries for the target triple into Swift SDK bundle...
rsync: --ignore-missing-args: unknown option
rsync error: syntax or usage error (code 1) at /AppleInternal/Library/BuildRoots/5bb93434-bef0-11ef-bef2-d285688f7a47/Library/Caches/com.apple.xbs/Sources/rsync/rsync/main.c(1337) [client=2.6.9]
@euanh euanh added the bug Something isn't working label Feb 13, 2025
@euanh
Copy link
Contributor Author

euanh commented Feb 13, 2025 •
edited
Loading

@xtremekforever Could you please see if there's an alternative way of handling missing directories in rsync which works for armv7 SDKs without using this flag?

euanh added a commit to euanh/swift-sdk-generator that referenced this issue Feb 13, 2025
@euanh
generator: The target toolchain is still needed to build a package-ba…
78a5a30 
…sed SDK

PR swiftlang#177 was intended to skip unnecessary toolchain downloads, making it
possible to build a container-based SDK offline if all its requirements
had already been dowloaded.  The change was too broad and also broke
building package-based SDKs.

PR swiftlang#177 skips calling generator.downloadArtifacts() when building
an SDK without an embedded host toolchain (the default).   In
addition to downloading the host toolchain (and LLVM, if needed),
generator.downloadArtifacts() is also responsible for downloading
the target toolchain.  This is not needed when building a container-based
SDK but is required when building a package-based SDK, which combines
an SDK from swift.org with supporting libraries extracted from
Debian packages.

In fact, generator.downloadArtifacts() already avoids downloading
toolchains when building a container-based SDK without an embedded
toolchain.   The only network call which caused offline builds to
fail was an unconditional check for a suitable LLVM binary from
GitHub.

This PR restores the call to generator.downloadArtifacts() and only
makes the LLVM check if LLVM is in the list of required downloads.
This allows the EndToEnd tests to pass again (with PR swiftlang#170 temporarily
reverted because of issue swiftlang#181).
@euanh euanh mentioned this issue Feb 13, 2025
Merged
euanh added a commit that referenced this issue Feb 14, 2025
@euanh
generator: The target toolchain is still needed to build a package-ba…
a9f8e2a 
…sed SDK (#182)

PR #177 was intended to skip unnecessary toolchain downloads, making it
possible to build a container-based SDK offline if all its requirements
had already been dowloaded.  The change was too broad and also broke
building package-based SDKs.

PR #177 skips calling generator.downloadArtifacts() when building
an SDK without an embedded host toolchain (the default).   In
addition to downloading the host toolchain (and LLVM, if needed),
generator.downloadArtifacts() is also responsible for downloading
the target toolchain.  This is not needed when building a container-based
SDK but is required when building a package-based SDK, which combines
an SDK from swift.org with supporting libraries extracted from
Debian packages.

In fact, generator.downloadArtifacts() already avoids downloading
toolchains when building a container-based SDK without an embedded
toolchain.   The only network call which caused offline builds to
fail was an unconditional check for a suitable LLVM binary from
GitHub.

This PR restores the call to generator.downloadArtifacts() and only
makes the LLVM check if LLVM is in the list of required downloads.
This allows the EndToEnd tests to pass again (with PR #170 temporarily
reverted because of issue #181).
@xtremekforever
Copy link
Contributor

Oops! I'll have a look today. I'm sure it can be a simple fix.

@euanh euanh mentioned this issue Feb 25, 2025
Merged
MaxDesiatov added a commit to xtremekforever/swift-sdk-generator that referenced this issue Feb 25, 2025
@MaxDesiatov
Merge branch 'main' into swiftlang#181-fix-rsync-macos
a78fd38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Replace --ignore-if-missing with local file check xtremekforever/swift-sdk-generator
2 participants
@xtremekforever @euanh