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.
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.
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
chore: Build Wasmer on musl #2003
chore: Build Wasmer on musl #2003
Changes from all commits
5290185
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are target and build the same here? It seems like they could be different
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
matrix.target
andmatrix.os
are names defined by either Rust or GitHub.matrix.build
is something we chosse on our side so I prefer to rely on our naming convention here.If GitHub forces us to change the
os
this will not impact the workflow. Same fortarget
(even if it's unlikely they will change)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure that makes sense, I just want to check that there aren't extra semantics here. If I remember correctly, arm64 Mac used
target
or some other key for a very specific purpose and I think the difference might have been important because of cross-compilation or somethingThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkMcCaskey yeah, to build for M1 we cross compile so we define (in the matrix) the Rust target to use and we were also using this in our conditionals.
But now, we have a problem: when GitHub will support M1 directly, we won't cross-compile anymore (we won't force the target through the matrix). Without my change, this would also require to change all the conditionals. With my change, we only update the matrix and we are done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this new approach. It's more “error-proof”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was actually just about to comment that I think it's more error prone as we'll silently fail if we're missing any of these files and will just have to wait until a user reports or we notice that we didn't release one of the files we intended to.
Ideally our packaging logic would be tested and not live in our CI file. We've lost a ton of things done in CI over time from all the CI migrations we've done -- I wouldn't put anything too critical there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think the above code is better though, but we do need tests for our packaging logic and the change above makes the need for tests greater.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkMcCaskey the problem with our previous strategy here was we relied on the host OS to define the files to copy.
This is not always the right thing to do, for example when we cross-compile this is why I changed that. Also, our strategy was not adaptative: if a user decides to change his build configuration (for example move from
cdylib
tostaticlib
) he'll have to change the Makefile. With this change, everything will automatically work.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense, my one concern is just that it's less specific. Rather than encoding an expected state of the world "given condition X, we must have files Y, Z, ..." we just take whatever is there. So any bug that affects the files we produce will now go unnoticed. Put another way, the new code is less brittle and picky, but it's so non-brittle and picky that it won't complain if things are broken, where the old code would.
I think the real fix is to just have actual testing for our release process but I think that's out of scope for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's accept the present patch, and then immediately open a new PR to test the
package/
directory? We also have various scheduled tests that run basedwasmer-nightly
(like inwasmer-go
,wasmer-php
etc.).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change related to musl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope.
It can be extracted to a dedicated PR if needed.