Do not create dangling symlink in Android SDK artifactbundle

[marcprux]

Fixes #535

[finagolfin]

Have you tested building with this locally?

[marcprux]

Have you tested building with this locally?

No. TBH, I was hoping to get this in and then test the resulting .artifactbundle that gets produced…

[finagolfin]

OK, let me test it locally, then we can get this in. No hurry, as the next patch release likely won't be till next month.

[jakepetroules]

Thanks for the quick fix. However, please note that there are multiple dangling symlinks:

$ find . -type l
./swift-android/swift-resources/usr/lib/swift_static-aarch64/clang
./swift-android/swift-resources/usr/lib/swift-armv7/clang
./swift-android/swift-resources/usr/lib/swift_static-armv7/clang
./swift-android/swift-resources/usr/lib/swift-x86_64/clang
./swift-android/swift-resources/usr/lib/swift/clang
./swift-android/swift-resources/usr/lib/swift_static-x86_64/clang
./swift-android/swift-resources/usr/lib/swift-aarch64/clang

./swift-android/swift-resources/usr/lib/swift/clang is the one that points to the absolute path, while the other 6 are pointing to ../swift/clang, so they themselves will become dangling once this one is removed.

Can you remove the others as well and have the script create them on demand?

Since the script is no longer needed with SwiftPM's Swift Build backend, I'd like to avoid baking in assumptions that the script will be run (and then we can simply remove the script in 6.5 or 6.6 or whenever we end up removing the legacy build backend).

[marcprux]

Can you remove the others as well and have the script create them on demand?

Ahh, I thought only the absolute symlink was the issue.

I agree that we should move that link creation over to the post-install script, but that will require a bit more careful work, since those dangling symlinks are currently being "filled in" by the post-install script. We will instead need to make the script perform the link creation instead.

(and then we can simply remove the script in 6.5 or 6.6 or whenever we end up removing the legacy build backend)

I look forward to that future 😶

[finagolfin]

Oh, I think I remember now why we put it in: we added the other symlinks to this central one, then archiving the bundle failed or something if they were all pointing at a non-existent symlink, so I put this in as a place-holder.

I will confirm that is the reason and let you know, but either way, we'll likely need to ship with all of them, or add all of them after installation.

[finagolfin]

I'm building locally now without that last symlink, will let you know what I find.

[finagolfin]

Forgot about this as bigger stuff came up... the current plan is to ditch this install script altogether with the 6.4 release, as swift sdk configure now works in trunk and swift-build has other ways of working around these issues. I'm not sure these dangling symlinks really matter in 6.3 alone in the meantime.

I could not reproduce the build error I saw before on CI, when building locally now outside Docker, but that doesn't mean the CI won't still hit it. If you still want to clean this up, maybe replace all the symlinks with symlinks created in the install script when run by the user? No symlinks in the bundle means it won't fail when building, and Jake's dangling symlink concern would be addressed..