Open matthewfeickert opened 5 months ago
I think this is to some degree some of the pains of PR https://github.com/scikit-hep/fastjet/pull/4 again in a different format. Moving the underlying build system off of autogen
would help a lot I think.
I emailed the FastJet developers on this back on 2024-06-24 and Gavin responded quickly with the following:
Do you have working builds of FastJet behaving as expected for Apple silicon macOS?
Yes, we do, regularly (and I just double checked a fresh clone on my M2). But we haven’t tried builds where libtool comes from some other source — that range of variation goes beyond what we would normally explore.
I can see that the
autogen.sh
script could fail in that context. Mostly what that script is doing is checking that all tools are available, and clearly that’s not diagnosing things correctly for the situation you have in mind.An alternative to
autogen.sh
is to runcd plugins/SISCone/siscone && autoreconf -i && cd ../../.. && autoreconf -i ./configure [with your usual args]
That would simply assume all tools are correctly available. Might that offer an adequate workaround?
Best, Gavin
I haven't tried this yet on my Apple silicon machine, but this might be something we should try.
As in https://github.com/conda-forge/fastjet-feedstock/issues/10, trying to build with
macos-latest
(macos-14
) andauto64
fails in the building wheels stage withDetails:
``` Building wheels for collected packages: fastjet Created temporary directory: /private/var/folders/b3/2xm02wpd21qgrpkck5q1c6k40000gn/T/pip-wheel-b__xkee5 Destination directory: /private/var/folders/b3/2xm02wpd21qgrpkck5q1c6k40000gn/T/pip-wheel-b__xkee5 Building wheel for fastjet (pyproject.toml): started Running command Building wheel for fastjet (pyproject.toml) running bdist_wheel running build running build_py creating build creating build/lib.macosx-11.0-arm64-cpython-312 creating build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/version.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/_singleevent.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/__init__.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/_pyjet.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/_multievent.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/_generalevent.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet copying src/fastjet/_utils.py -> build/lib.macosx-11.0-arm64-cpython-312/fastjet running egg_info writing src/fastjet.egg-info/PKG-INFO writing dependency_links to src/fastjet.egg-info/dependency_links.txt writing requirements to src/fastjet.egg-info/requires.txt writing top-level names to src/fastjet.egg-info/top_level.txt reading manifest template 'MANIFEST.in' adding license file 'LICENSE' writing manifest file 'src/fastjet.egg-info/SOURCES.txt' running build_ext patching file 'src/ClusterSequence.cc' Detected Mac OSX On Mac OSX, ./autogen.sh requires the GNU libtool and libtoolize scripts, renamed glibtol and glibtoolize respectively by Apple to avoid conflict with Apple-provided libtool. They should be already installed, together with Apple developer tools, in /usr/bin. If you see this message, they are not. The GNU version can be retrieved from http://ftp.gnu.org/gnu/libtool/. If they are (re)installed from sources in a different location, autogen.sh should then be modified accordingly. make: *** No targets specified and no makefile found. Stop. Traceback (most recent call last): File "/private/var/folders/b3/2xm02wpd21qgrpkck5q1c6k40000gn/T/cibw-run-xlbfqb8i/cp312-macosx_arm64/build/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, inwith the relevant
which comes from the
fastjet
C++ source code'sautogen.sh
:The best thing would be to fix this up upstream, but this also need to get fixed in the releases we have out now with patching the wheel buidling.