-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
bun: Update to v1.2.22 #29333
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
base: master
Are you sure you want to change the base?
bun: Update to v1.2.22 #29333
Conversation
Notifying maintainers: |
The PR check for macOS-13 is failing because it's trying to pull in Is there something else I need to do to exclude i386/x86? |
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.
@iamGavinJ looks like with these changes you're just downloading binaries. Beforehand it appears the package was build from source; that is what we want to do in MacPorts. So unless I'm misunderstanding this PR I doubt we want to merge this.
This is exactly what the My change achieves exactly the same thing without indirection. |
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.
The PR check for macOS-13 is failing because it's trying to pull in
i386
but I've addedsupported_archs arm64 x86_64
to thePortfile
so I'm not sure why it's doing that.
Because you've based distname
on os.arch
. os.arch
only ever has one of three possible values: powerpc
(on PowerPC Macs), i386
(on Intel Macs) or arm
(on Apple Silicon Macs).
How are those binaries built, and can the Portfile do that instead? MacPorts is a build from source system, not an install somebody else's binaries system. |
When I first looked into building it, there was no documentation, which is why I used the NPM port group. Now it seems there is documentation, so it might be possible to change it to build from source. However, it does seem to require itself as a dependency, which may complicate things. |
That does complicate, but that could be a place where you could use the binaries they provide in order to build our own copy. However, do check if there's a way to build bun without requiring bun. It seems like there must be a way, otherwise how would they ever support a new platform? |
bun: Update to v1.2.22 bun: Resolving commends bun: Fixing x86_64 Build Arch bun: Fix Tcl Else-If typo bun: Add separate checksums for pre-built bins Temporary fix until true build from source is implemented.
5ce4f6c
to
dd432a2
Compare
bun: Update to v1.2.22
Description
npm
togithub
- IMO it should not be necessary to usenpm
to install the thing that replacesnpm
(andnode
).Type(s)
Tested on
macOS 15.6.1 24G90 arm64
Xcode 16.4 16F6
Verification
Have you
port lint
?sudo port test
?sudo port -vst install
?