bun 0.1.6 (new formula)

[jeelmakani]

• [x] Have you followed the guidelines for contributing?
• [x] Have you ensured that your commits follow the commit style guide?
• [x] Have you checked that there aren't other open pull requests for the same formula update/change?
• [x] Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[chenrui333]

@jeelmakani it need to be built from source.

[equal-l2]

Bun currently requires AVX2 on Intel: https://github.com/oven-sh/bun/issues/67

At least one of the action error occurring is caused by lacking AVX2:

  fastavxbase64.c:79:27: error: always_inline function '_mm256_maskload_epi32' requires target feature 'avx2', but would be inlined into function 'fast_avx2_base64_encode' that is compiled without support for 'avx2'
      __m256i inputvector = _mm256_maskload_epi32(

(log excerpt)

[rodrigoborgesdeoliveira]

Bun v0.1.4 is out.

[cho-m]

Bun currently requires AVX2 on Intel: oven-sh/bun#67

This will be a blocker. Homebrew needs to build bottles that can run on older hardware.

As I recall:

• Current macOS will be built with -march=nehalem (max SSE4.2).
• Current Linux will be built with -march=core2 (max SSSE3).

[equal-l2]

We can't use AVX2 for the time being because macOS 12 supports Mac Pro with Ivy Bridge, which doesn't support AVX2.

[equal-l2]

Bun 0.1.5 has been released. It contains AVX2 detection in the base64 module.

[cho-m]

Cancelling Monterey ARM runner as it has gone over 14 hours while Big Sur ARM only took 1.5 hours. Anyways, build failures on other runners need to be addressed.

[danielnachun]

I think we can reduce the build time greatly by not vendoring WebKit. JavaScriptCore is provided by JavaScriptCore.Framework on macOS, and on Linux by the recently added webkitgtk formula. I am somewhat inclined to say that if this cannot build agains the versions of JavaScriptCore we already provide, this would better suited for its own tap. I think we need to be conservative about accepting new formulae that build their own copies of WebKit, v8 or LLVM because these add substantially to the build time and are not following https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae.

[equal-l2]

They seems to be still working in progress on non-AVX2 build: https://github.com/oven-sh/bun/discussions/873#discussioncomment-3227335

This [build failure in base64 module] isn't the main issue facing non-AVX2 support. But I am working on it as we speak. Once this action runs successfully, we should have automated builds for macOS x64, macOS arm64, Linux arm64, Linux x64, Linux x64 for non-avx2 CPUs (-baseline) and macOS x64 for non-avx2 CPUs.

[equal-l2]

Bun 0.1.6 has been released. From this version, the upstream offers non-AVX2 (baseline) builds, which means we should be able to build Bun on non-AVX2 machines officially.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[chenrui333]

they have setup up the tap for now

[iMichka]

Do you want to try this again with version 0.2.2 or should we close this?

[danielnachun]

I think we never got a clear response as to whether we could avoid vendoring its dependencies, especially JavaScriptCore which is extremely slow to build in CI.

[iMichka]

Let's close this until we got more answers and a new proposal is made with the newest version. This has been open since July 6, and it's always a bad sign when a formula takes that much time to be approved.

[chenrui333]

#142016