Fix GitHub Actions workflow for macOS WHL build

[glowinthedark]

macOS WHL build github action fix

• fix GitHub Actions workflow for macOS WHL build build-macos.yml

• add optional alternative brew-based lzo alterantive that does not need building the sources under ./lzo-2.10 (pending confirmation for removal as irrelevant)

brew version is installed with brew install lzo

$ brew info lzo

==> lzo ✔: stable 2.10 (bottled)
Real-time data compression library
https://www.oberhumer.com/opensource/lzo/
Installed
/opt/homebrew/Cellar/lzo/2.10 (32 files, 581.6KB) *
  Poured from bottle using the formulae.brew.sh API on 2026-05-31 at 16:40:48
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/l/lzo.rb
License: GPL-2.0-or-later

Please let me know if you would rather prefer to not use the brew provided lzo and use instead the included source as in the original workflow.

I suppose that it should be doable, the key addition in this workflow apart from the cosmetic stuff is setting the env vars which python expects when building the wheels, so I suppose they would just have to point to the right paths under ./lzo-2.10

brew install lzo
LZO_PREFIX=$(brew --prefix lzo)
CFLAGS="-I${LZO_PREFIX}/include" \
LDFLAGS="-L${LZO_PREFIX}/lib -Wl,-rpath,${LZO_PREFIX}/lib" \

python -m build --wheel

I.e. my naive guess would be that something like this could work with local lzo sources:

CFLAGS="-I./lzo-2.10/include" \
LDFLAGS="-L./lzo-2.10/lib -Wl,-rpath,./lzo-2.10/lib" \

python -m build --wheel

[jd-boyd]

It looks to me like the macOS wheels using included LZO source are working, so I'm not sure what this is improving and for whom. Please correct me if I'm wrong about working or give me more information about who benefits from this.

Is the goal to support people building from source who don't want to install cmake, but do use brew?

Will this patch produce wheels that work for people who never use brew, either by linking against the static library or by including liblzo2.so in the wheel?

I'm not married to any specific method on maOS. I just want a solution that is easiest for mac users who do and don't use brew, who use system python or the latest via brew/uv/pyenv.

I'm not sure why CI didn't trigger on this. I will try to force that so that I can look at artifacts.

[glowinthedark]

@jd-boyd

who benefits from this?

that's exactly the point the PR is addressing - the beneficiaries would be the people who only want the WHL and don't want to or don't know how to install homebrew, xcode (10+ GB and growing) or xcode command line tools, and the entire full blown dev environment.

The current github workflow for macos build-macos.yml fails building in your repo. Moreover, even when fixed, the workflow only generates the WHL(s) without publishing them, and artifacts expire after whatever value github sets as the default number of days - I think it's something like 90 days, unless explicitly reconfigured in the workflow.

It's understandable that you might want to avoid publicly releasing WHLs in your repo but at least giving anyone the ability to fork your repo and then run the workflow in their fork to generate their own WHLs would be helpful, don´t you think?

[glowinthedark]

@jd-boyd also fixed the build-macos.yml workflow so that cmake build now works and no brew 'lzo' dependency is required.

what is changed/added:

• builds WHLs for python3.10..14 for both macos-14 and macos-15 (currently = macos-latest)
• optional release if the tag is manually specified during workflow_dispatch
• patches CMakeLists.txt to work around the deprecated version (I prefer not to edit directly CMakeLists.txt)

I suppose the other workflow that relies on lzo from homebrew can be discarded, no? Please advise what you prefer.

[jd-boyd]

It's understandable that you might want to avoid publicly releasing WHLs in your repo but at least giving anyone the ability to fork your repo and then run the workflow in their fork to generate their own WHLs would be helpful, don´t you think?

I am not trying to block that. It is either GitHub defaults or operator error. I will look into it.

[jd-boyd]

I suppose the other workflow that relies on lzo from homebrew can be discarded, no? Please advise what you prefer.

I apologize. At the danger of adding unwanted work on you, how about use brew lzo if it is there and fall back to cmake the included lzo if it isn't? I think that would be the best of both worlds.

If you don't like this, or it doesn't work for you, let me know.

[glowinthedark]

how about use brew lzo if it is there and fall back to cmake the included lzo if it isn't?

hmmm! I like the idea to merge both approaches. The full list of libraries and frameworks available in the ootb github runners is published on github, both macos-14 and macos-15 (both arm64) come with homebrew ootb, (macos-13, the intel arch runner, was decommissioned in 2025).

• https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
• https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md

Made a debug workflow that prints what brew formulas that are already pre-installed ootb -- lzo 2.10 is already there on both macos-14 and macos-15, so it is deterministic, and there is no need to explicitly run brew install lzo as I did in the additional workflow. Takes less time and spends less github runner minutes.

I do not know if the lzo 2.10 sources in your repo are patched in any specific way, and if they differ from what homebrew formula uses - I am assuming they are the same.

The homebrew formula at https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/l/lzo.rb pulls the original sources from https://www.oberhumer.com/opensource/lzo/ - if I understand correctly, Markus F.X.J. Oberhumer is the original author and copyright holder of LZO.

lzo 2.10 can be safely assumed to always be available on the two currently supported macos runners.

I merged the two approaches into one .yml with first attempt to build using ootb lzo, and if that fails then build from provided local source.

[jd-boyd]

I do not know if the lzo 2.10 sources in your repo are patched in any specific way, and if they differ from what homebrew formula uses - I am assuming they are the same.

They should be the same.

[glowinthedark]

forced a failure for the brew lzo to validate that the fallback actually does work as expected and it does:

here is the run: https://github.com/glowinthedark/python-lzo/actions/runs/26782087334/job/78948698960