Skip to content

Conversation

luoliwoshang
Copy link
Contributor

@luoliwoshang luoliwoshang commented Aug 27, 2025

  • Have you followed the guidelines for contributing?
  • Have you ensured that your commits follow the commit style guide?
  • Have you checked that there aren't other open pull requests for the same formula update/change?
  • Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 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 HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

feature
  • building esp-clang from source
  • add test embed target
verify in follow platform
  • macos arm64
  • macos amd64
  • linux arm64
  • linux amd64

@github-actions github-actions bot added the go Go use is a significant feature of the PR or issue label Aug 27, 2025
@luoliwoshang luoliwoshang force-pushed the llgo/embbuild1 branch 2 times, most recently from 9334c0c to 98834fb Compare August 27, 2025 07:37
@stefanb stefanb added the prerelease-testing Pull request from upstream, testing a pre-release with homebrew dependencies label Aug 27, 2025
@github-actions github-actions bot added the autosquash Automatically squash pull request commits according to Homebrew style. label Aug 27, 2025
@github-actions github-actions bot removed the autosquash Automatically squash pull request commits according to Homebrew style. label Aug 27, 2025
@daeho-ro daeho-ro marked this pull request as draft August 27, 2025 12:48
@luoliwoshang
Copy link
Contributor Author

Hi @carlocab ,
I hope you're doing well! I'm working on a formula for llgo that has a dependency on a custom-built espressif/llvm-project (Fork of LLVM with Xtensa specific patches).
The build process is currently exceeding the default time limits in the CI system, which is causing build failures. Given that this involves building LLVM from source with custom patches, it's inherently a time-intensive process.
Would it be possible to add the long_build label to this formula? This would help accommodate the extended build time required for the LLVM compilation.
I really appreciate your time and assistance with this. Thank you for all the great work you do maintaining Homebrew!
Best regards

@luoliwoshang luoliwoshang changed the title llgo:pretest embed customize clang [wip] llgo:pretest embed customize clang Aug 31, 2025
@luoliwoshang luoliwoshang marked this pull request as ready for review August 31, 2025 07:30
@luoliwoshang
Copy link
Contributor Author

Hi @chenrui333 , hope you're having a great day!
I'm submitting a formula for llgo that depends on a custom espressif/llvm-project build (LLVM fork with Xtensa-specific patches). The formula is running into CI timeout issues since building LLVM from source with these patches takes quite a while.
I was wondering if we could add the long_build label to help with the extended compilation time? The LLVM build process is naturally time-consuming, especially with the custom patches included.
Thanks so much for taking a look, and really appreciate all the amazing work you do for the Homebrew community!
Cheers!

llvm build cache

with mac cgo config

with c++17

-Wl,-rpath with llvm

remove CFLAG unset by goplus/llgo#1243 merged

with llgo embed target build test

DRUNTIMES_CMAKE_ARGS set RPATH

clang prefix

linux rpath

-DLLVM_ENABLE_LIBEDIT=OFF

refine rb struct

llvm test off

remove some llvm component as tinygo

build only nessary executable

-DLLVM_INSTALL_UTILS=OFF
@stefanb stefanb marked this pull request as draft September 1, 2025 04:41
@stefanb stefanb added the long build Set a long timeout for formula testing label Sep 1, 2025
Comment on lines +35 to 39
resource "espressif-llvm" do
url "https://github.com/espressif/llvm-project.git",
revision: "xtensa_release_19.1.2",
shallow: true
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are your plans for upstreaming your changes from this fork?

We're not that keen on another custom build of LLVM here.

Copy link
Contributor Author

@luoliwoshang luoliwoshang Sep 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlocab Thank you for your feedback!
I appreciate you bringing this up! We don't actually maintain or fork Espressif's LLVM repository—our executable simply uses it as a compiler to support building code for Xtensa architecture chips (such as ESP32) in llgo.
From what I understand, Espressif is actively working on upstreaming their Xtensa modifications to LLVM mainline. You can track their progress here: Tracking Issue for merging to upstream (LLVM-57) · Issue #4 · espressif/llvm-project.
We're also hoping this formula can eventually be merged into Homebrew/core, which would allow users to access it directly through the standard brew install llgo command without needing additional taps or custom configurations. This would greatly improve llgo's accessibility and community adoption.

Copy link
Member

@carlocab carlocab Sep 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced that this formula is sufficiently popular to warrant the maintenance burden of yet another custom LLVM build here, I'm afraid. (See analytics data here.)

It looks to me that @espressif releases binary builds of their toolchain (example), so what we should probably do is stick with the LLVM formula here, but make it easier for users to use a custom toolchain with this formula.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go Go use is a significant feature of the PR or issue long build Set a long timeout for formula testing prerelease-testing Pull request from upstream, testing a pre-release with homebrew dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants