[WIP] OSX support #377
Draft
[WIP] OSX support #377
+192
−228
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
beauby
force-pushed
the
osx-support
branch
2 times, most recently
from
72be6ff
to
e986cd4
Compare
Context: The `sklib` file format is a ranlib archive that contains possible object files from C extensions, as well as skip-specific metadata. It can thus be passed straight to the linker, or be used by `skc`. Part of the required metadata is information about the defined (skip) symbols in the sklib. In practice, we pack the source code of all files from the package into the sklib. So far, the skip source files were embedded as members of the ranlib archive, which works fine on Linux as the linker seems to ignore files that are not ELF objects, but causes issues on OSX, where the linker complains about non Mach-O files. In order to work around this, the idea is to pack the source files of the package along with the metadata inside the `lib.skmeta` member of the archive. This would still be an issue, but the next step is to embed the `lib.skmeta` into a dummy object file, leaving a clean ranlib archive that should please any linker.
The previous implementation had a bug: it would lose track of the "analyzed" status of files not within the current invocation's dependency graph, causing it to keep stale analysis around in some cases. The new implementation is hopefully easier to follow, and although it does a bunch of O(n^2) operations on lists of known packages, it shouldn't matter much in the near future (they are still identified by a `FIXME` comment for further attention).
jberdine
reviewed
Oct 9, 2024
| modified_files = mutable Vector[]; | ||
| deleted_files = mutable Vector[]; | ||
|
|
||
| // FIXME: This is O(n^2). |
There was a problem hiding this comment.
Are the srcs arrays already sorted? A linear traversal of new_srcs seems unavoidable. So perhaps the best that can be done is to sort old_srcs and use a binary search instead of Array.find. Maybe it would be better to also sort new_srcs and then be able to narrow the binary search of old_srcs at each step.
That's correct. The aim of this branch is to get OSX support down the line, and I made it a PR for visibility. I'll split self-contained commits out into separate PRs. |
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.
No description provided.