nesfab 1.6 (new formula) #211113

vtbassmatt · 2025-03-16T20:53:11Z

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>?

Adds NESFab. NESFab is a programming language/compiler for creating NES games. It qualifies for inclusion in Homebrew because it's maintained (v1.6 came out within the last week), is known (689 GitHub stars), is used (there has been recent GitHub and Discord activity related to macOS builds), and has a homepage.

github-actions · 2025-03-16T21:04:13Z

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

vtbassmatt · 2025-03-17T00:03:45Z

Hi Homebrew maintainers. I'm feeling stuck after multiple rounds of searching, editing, and resubmitting. I feel like I'm missing something simple.

This project uses a C++20 feature (std::lexicographical_compare_three_way) which Clang apparently didn't fully support until libc++ 17. I searched discussions and found https://github.com/orgs/Homebrew/discussions/5977 which led to #188332, which I aped in my formula:

# ...
  on_macos do
    depends_on "llvm" => :build if DevelopmentTools.clang_build_version <= 1599
  end
# ...
  fails_with :clang do
    build 1599
    cause "Missing std::lexicographical_compare_three_way"
  end

However, the build still fails on macOS 13. (It builds on macOS 15 because I happened to get a successful run there. The PR has always failed before trying macOS 14, so I'm not confident whether it succeeds or fails there.)

I see two paths forward:

Correct my use of depends_on / fails_with to ensure we get a version of libc++ that works; I need someone with more Clang expertise to point me in the right direction here.
Remove macOS 13 (and possibly 14?) from the set of supported platforms. Upstream wouldn't build locally (by default) on that/those platforms, so this might also be acceptable.

Thanks for any help you can offer!

botantony · 2025-03-17T00:28:47Z

@vtbassmatt I think this error happens because it still uses system Clang. Set CXX to the full path to Homebrew's LLVM Clang if clang_build_version is less that 1600

vtbassmatt · 2025-03-17T00:32:07Z

@vtbassmatt I think this error happens because it still uses system Clang. Set CXX to the full path to Homebrew's LLVM Clang if clang_build_version is less that 1600

Thank you! I see now that the PR I copied from was using CXX=#{ENV.cxx} and I was not. I've kicked another build to see if this does it.

SMillerDev · 2025-03-17T08:42:37Z

  Failed to execute /opt/homebrew/opt/llvm/bin/clang++ -w -Os -std=c++20 -pthread -Wno-unused-parameter -Wno-unknown-warning-option -Wno-narrowing -Wno-missing-field-initializers -Wno-missing-braces -Wno-unused-command-line-argument -fmax-errors=3 -ftemplate-depth=100 -pipe -Isrc -DVERSION="1.6" -DGIT_COMMIT="da18a43d-homebrew" -DNDEBUG -Wno-unused-variable -c -o obj/token.o src/token.cpp -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -isystem/opt/homebrew/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/opt/homebrew/opt/icu4c@77/include -I/opt/homebrew/opt/llvm@16/include -fdebug-prefix-map=/private/tmp/nesfab-20250316-8709-5r20tf/nesfab-da18a43dc7b941cc4c56c949303aa37633fdc1b0=.
  
  Xcode and/or the CLT appear to be misconfigured. Try one or both of the following:
    xcodebuild -license
    sudo xcode-select --switch /path/to/Xcode.app

vtbassmatt · 2025-03-17T09:02:43Z

  Failed to execute /opt/homebrew/opt/llvm/bin/clang++ -w -Os -std=c++20 -pthread -Wno-unused-parameter -Wno-unknown-warning-option -Wno-narrowing -Wno-missing-field-initializers -Wno-missing-braces -Wno-unused-command-line-argument -fmax-errors=3 -ftemplate-depth=100 -pipe -Isrc -DVERSION="1.6" -DGIT_COMMIT="da18a43d-homebrew" -DNDEBUG -Wno-unused-variable -c -o obj/token.o src/token.cpp -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -isystem/opt/homebrew/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/opt/homebrew/opt/icu4c@77/include -I/opt/homebrew/opt/llvm@16/include -fdebug-prefix-map=/private/tmp/nesfab-20250316-8709-5r20tf/nesfab-da18a43dc7b941cc4c56c949303aa37633fdc1b0=.
  
  Xcode and/or the CLT appear to be misconfigured. Try one or both of the following:
    xcodebuild -license
    sudo xcode-select --switch /path/to/Xcode.app

Yep, a new hell 😁 because a different thing breaks when I use llvm@latest, so I’m trying to use llvm@16 to match what works on macOS 14 & 15. I had to go to bed so didn’t get a chance to troubleshoot this one last night.

vtbassmatt · 2025-03-17T12:37:39Z

😭 OK, I'm crying uncle. I cannot seem to get this building on macOS 13.

It builds with gcc, but then doesn't link because its dependency (Boost) was built with Clang
- Possible solution: build Boost myself using GCC (and link statically). This is at odds with https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae. The purity-vs-usefulness distinction offers some leeway to do this, but getting Boost building feels both heavyweight and yak-shave-y.
It doesn't build with the macOS 13 default Clang because std::lexicographical_compare_three_way wasn't part of that libc++
- No solution found: I don't think upstream will accept removing this call. It's part of the C++20 standard, and apparently offers significant runtime savings. Older Clang was not fully implementing the standard yet.
It doesn't build with depends_on: 'llvm' (which is @19) because that libc++ removed char_traits<unsigned char>
- Possible solution: I'm working with upstream to get this fixed. There may still be an onion-peeling exercise to see what else has dropped/changed between Xcode's LLVM on Sequoia and bleeding-edge LLVM.
It doesn't build with depends_on: 'llvm@18' (or 17 or 16) because every compiler invocation fails with:

Xcode and/or the CLT appear to be misconfigured. Try one or both of the following:
  xcodebuild -license
  sudo xcode-select --switch /path/to/Xcode.app"

Number 4 perplexes me the most. It actually seems like the correct path forward, if someone can help me understand what I need to do in the Homebrew CI to get this fixed.

xcodebuild -license requires user-at-keyboard (I think? I couldn't figure out how to do it headless).
I don't know where to tellxcode-select to look for some different Xcode.
I tried adding the LDFLAGS suggested in https://formulae.brew.sh/formula/llvm@18, but that didn't fix anything.

Help, please 🙏

botantony · 2025-03-17T13:37:44Z

@vtbassmatt instead of LDFLAGS try to use this:

ENV.prepend_path "HOMEBREW_LIBRARY_PATHS", Formula["llvm@18"].opt_lib/"c++"

vtbassmatt · 2025-03-17T14:18:47Z

@vtbassmatt instead of LDFLAGS try to use this:
ENV.prepend_path "HOMEBREW_LIBRARY_PATHS", Formula["llvm@18"].opt_lib/"c++"

Thanks. Gave it a try, and it still failed in the same way. I've cribbed some stuff from the llvm@18 test stanza that I'm trying now:

      toolchain_path = "/Library/Developer/CommandLineTools"
      cpp_base = (MacOS.version >= :big_sur) ? MacOS::CLT.sdk_path : toolchain_path

      system "make", "GIT_COMMIT=#{git_sha}-homebrew", "CXX=#{ENV.cxx}",
             "-isysroot", MacOS::CLT.sdk_path,
             "-isystem", "#{cpp_base}/usr/include/c++/v1",
             "-isystem", "#{MacOS::CLT.sdk_path}/usr/include",
             "-isystem", "#{toolchain_path}/usr/include",
             "release"

though I'm not sure what Make will do with those -isys* lines.

SMillerDev · 2025-03-17T14:42:06Z

It doesn't build with the macOS 13 default Clang because std::lexicographical_compare_three_way llvm/llvm-project#68591

Seems like the easiest way is declaring that it needs at least macOS 14 to build.

vtbassmatt · 2025-03-17T14:47:59Z

It doesn't build with the macOS 13 default Clang because std::lexicographical_compare_three_way llvm/llvm-project#68591

Seems like the easiest way is declaring that it needs at least macOS 14 to build.

That's the conclusion I've arrived at as well 🤣. I'm going to try dropping Ventura before I pull any more hair out.

vtbassmatt · 2025-03-17T15:09:01Z

Appreciate everyone's help getting here! Yup, it turned out that I just needed to say "so long" to Ventura / macOS 13. It builds on 14+.

vtbassmatt · 2025-03-23T19:01:16Z

@SMillerDev sorry to bother you - do I need to do anything else to have this contribution accepted?

SMillerDev · 2025-03-24T10:03:43Z

Formula/n/nesfab.rb

+  # for this version only, point to a specific commit. post-1.6, this will point to a tagged release.
+  url "https://github.com/pubby/nesfab/archive/da18a43dc7b941cc4c56c949303aa37633fdc1b0.tar.gz"
+  version "1.6"


We'll need to wait for a tagged release

OK, I will ask upstream if they can do a small release so we have something to point to.

Formula/n/nesfab.rb

SMillerDev · 2025-03-24T10:04:58Z

Formula/n/nesfab.rb

+      system "make", "clean"
+      system "make", "GIT_COMMIT=#{git_sha}-homebrew", "CXX=#{ENV.cxx}", "debug" if Hardware::CPU.intel?
+      system "make", "GIT_COMMIT=#{git_sha}-homebrew", "CXX=#{ENV.cxx}", "ARCH=", "debug" if Hardware::CPU.arm?
+      bin.install "nesfab"


We don't want to build debug builds

This formula is for a compiler. The debug flavor inserts runtime checks into the generated code to help with the development experience, while the release flavor doesn't since the target system is very resource-constrained. It's definitely unusual that upstream chose to make these two different builds rather than an option to a single binary, but refactoring that is beyond the scope of adding to a package manager. Both are necessary for a full development environment.

Is there another naming convention I could use for the binaries, or some other way to make this fit the spirit of the Homebrew policy without major surgery on upstream's architectural choice?

if both flavors are useful, we can probably install both. (this also sounds like static/dynamic shared lib)

OK, great. If this aspect won't be a blocker, I believe that's the last open question from Homebrew. I'll see if upstream is willing to cut a release, I can point to it, and maybe get this thing merged!

SMillerDev · 2025-03-24T10:05:19Z

Formula/n/nesfab.rb

+    if OS.mac?
+      system "make", "GIT_COMMIT=#{git_sha}-homebrew", "CXX=#{ENV.cxx}", "release" if Hardware::CPU.intel?
+      system "make", "GIT_COMMIT=#{git_sha}-homebrew", "CXX=#{ENV.cxx}", "ARCH=", "release" if Hardware::CPU.arm?
+      bin.install "nesfab" => "nesfab-release"


Is there no make install?

There is not. Upstream builds a single binary and so recommends people to simply build the thing and copy it into someplace in $PATH.

Formula/n/nesfab.rb

github-actions · 2025-04-14T13:25:21Z

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.

vtbassmatt · 2025-04-14T14:15:01Z

Not stale. Waiting until upstream does a point release that I can rebase to.

chenrui333 · 2025-05-30T03:18:30Z

upstream has made a 1.6_mac release, https://github.com/pubby/nesfab/releases/tag/v1.6_mac?

vtbassmatt · 2025-05-30T10:18:44Z

upstream has made a 1.6_mac release, https://github.com/pubby/nesfab/releases/tag/v1.6_mac?

Unfortunately it didn’t have everything needed to land a working Homebrew package.

Enough time has elapsed now that perhaps the maintainer can be persuaded to do another point release. I was waiting to see if anyone had more thoughts on #211113 (comment) though.

chenrui333 · 2025-05-30T14:24:27Z

Enough time has elapsed now that perhaps the maintainer can be persuaded to do another point release.

yeah, probably, also better to move the installation process into the upstream as well (like one goal to install both flavors)

github-actions bot added new formula PR adds a new formula to Homebrew/homebrew-core boost Boost use is a significant feature of the PR or issue labels Mar 16, 2025

vtbassmatt force-pushed the add-nesfab branch 10 times, most recently from c51f52b to 20a8846 Compare March 16, 2025 23:41

vtbassmatt force-pushed the add-nesfab branch from 20a8846 to 9021654 Compare March 17, 2025 00:31

vtbassmatt force-pushed the add-nesfab branch from 9021654 to 697bfe2 Compare March 17, 2025 01:40

vtbassmatt force-pushed the add-nesfab branch 8 times, most recently from 42544d8 to 57533dc Compare March 17, 2025 11:27

vtbassmatt force-pushed the add-nesfab branch 2 times, most recently from f3c715d to e8b4988 Compare March 17, 2025 14:15

vtbassmatt force-pushed the add-nesfab branch from e8b4988 to e51ed02 Compare March 17, 2025 14:35

vtbassmatt force-pushed the add-nesfab branch from e51ed02 to 6a96f6c Compare March 17, 2025 14:49

SMillerDev reviewed Mar 24, 2025

View reviewed changes

nesfab 1.6 (new formula)

676ba3c

vtbassmatt force-pushed the add-nesfab branch from 6a96f6c to 676ba3c Compare March 24, 2025 12:00

github-actions bot added the stale No recent activity label Apr 14, 2025

github-actions bot removed the stale No recent activity label Apr 14, 2025

daeho-ro added the in progress Stale bot should stay away label Apr 16, 2025

vtbassmatt mentioned this pull request May 30, 2025

Mac Version pubby/nesfab#14

Open

Uh oh!

nesfab 1.6 (new formula) #211113

Are you sure you want to change the base?

nesfab 1.6 (new formula) #211113

Uh oh!

Conversation

vtbassmatt commented Mar 16, 2025

Uh oh!

github-actions bot commented Mar 16, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

botantony commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025

Uh oh!

SMillerDev commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025

Uh oh!

botantony commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025

Uh oh!

SMillerDev commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025

Uh oh!

vtbassmatt commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vtbassmatt commented Mar 23, 2025

Uh oh!

SMillerDev Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

vtbassmatt Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

SMillerDev Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

vtbassmatt Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chenrui333 May 30, 2025

Choose a reason for hiding this comment

Uh oh!

vtbassmatt May 30, 2025

Choose a reason for hiding this comment

Uh oh!

SMillerDev Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

vtbassmatt Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Apr 14, 2025

Uh oh!

vtbassmatt commented Apr 14, 2025

Uh oh!

chenrui333 commented May 30, 2025

Uh oh!

vtbassmatt commented May 30, 2025

Uh oh!

chenrui333 commented May 30, 2025

Uh oh!

Uh oh!

vtbassmatt commented Mar 17, 2025 •

edited

Loading

vtbassmatt commented Mar 17, 2025 •

edited

Loading

vtbassmatt Mar 24, 2025 •

edited

Loading