Build on MacOS

[murilobalves]

With the help of AI chatbot, I modified trackcpp compilation/installation to build it in MacOS.

Branch tested on:

• macOS: macOS 15.6.1 (Sequoia), arm64 (Apple Silicon), Apple clang 17.0.0. Conda env (gsl 2.8, swig 4.2.0, python 3.11.13, numpy 2.3.3, conda-forge). Full build (libtrackcpp.a, trackcpp binary, and the SWIG-generated _trackcpp.so Python extension).
• Linux: Rocky Linux 8.10, x86_64, GCC 8.5.0 (system compiler). Conda env (gsl 2.8, swig 4.4.1, python 3.11.15, numpy 2.4.6, conda-forge). Full build unaffected.

I would appreciate if you could test the branch on the LNLS computers as well. Thanks!

---

[AI-generated summary] Fix macOS build (Apple Clang + conda toolchain)

trackcpp didn't build on macOS. This fixes it without changing behavior on Linux/GCC.

include/trackcpp/auxiliary.h, src/trackcpp.cpp — guard the custom isfinite shim to real GCC only.
#if __GNUC__ < 6 was meant to declare a fallback isfinite for old GCC that lacks std::isfinite. Apple Clang also defines __GNUC__ (for compatibility) at a value < 6, so this shim got compiled on macOS too, colliding with the standard library's own isfinite/std::isfinite. Changed to defined(__GNUC__) && !defined(__clang__) && __GNUC__ < 6 in both the declaration and the definition. No effect on real GCC builds.

Makefile — two independent fixes:

• $(CXX) -MM ... (auto-dependency generation) ran without $(INC), so on macOS it can't resolve include paths (e.g. GSL from a non-default prefix) and fails/produces a broken .depend. Added $(INC) to the invocation.
• Added LDFLAGS += -Wl,-rpath,$(CONDA_PREFIX)/lib when $(CONDA_PREFIX) is set, so the binary can find libraries (e.g. GSL) installed in the active conda env at runtime — macOS doesn't fall back to the same default library search paths Linux does. No-op when not in a conda env.

python_package/Makefile — three fixes, all macOS-specific via a new UNAME_S := $(shell uname -s) branch (Linux path is untouched):

• Linking a Python extension .so on macOS needs -bundle -undefined dynamic_lookup, not -shared (ld64 doesn't support -shared the way GNU ld does for Python modules); added a SOFLAGS variable, Darwin vs. else.
• GNU ld's -Wl,--whole-archive ... --no-whole-archive (used to force-link all of libtrackcpp.a into the extension) isn't supported by macOS's linker; the equivalent is -Wl,-force_load,$(TRACKCPPLIB). Added an ARCHIVE_LINK variable, same branch.
• The -MM dependency generation had the same missing-$(INC) problem as the top-level Makefile (can't find Python/numpy/GSL headers); fixed the same way.
• numpy.i was fetched with a hardcoded wget call; wget isn't installed by default on macOS. Falls back to curl -sL when wget isn't on PATH.

src/output.cpp — fprintf(fp, "...%s...", rad_dict[accelerator.radiation_on]) passed a std::string directly through a varargs %s, which is undefined behavior (relies on the string's internal ABI layout rather than a const char*). It happened to work under libstdc++/GCC but breaks under libc++/Clang. Fixed all 4 call sites (print_closed_orbit, print_tracking_linepass, print_tracking_ringpass, print_dynapgrid) to use .c_str(). This is a real correctness fix, not macOS-only — worth taking regardless of platform.

[fernandohds564]

I tested this branch in my computer and at lnls449. The test consisted in compiling the code and calculate the twiss parameters for the SIRIUS model. It worked on both computers.

[VitorSouzaLNLS]

I also tested it on my PC (Debian 12 @ WSL - Windows 11), and it worked correctly.