Not actually sure if this is caused when scipy was updated in ports ef9180aa84690bd5181cd60be75c891ee7bdb74e or if it's due to the numpy/numpy1 shakeup, but I am unable to build science/py-scipy [see below for the workaround I found while writing this report]. As an aside, I was forced to "pkg delete -f py311-numpy" because it wanted to upgrade to numpy 2, and py-scipy now has an explicit BUILD_DEPENDS on math/py-numpy1 --- which it refused to install after py311-numpy was updated because they conflict. The vast majority of the ports I have that depend on scipy *also* depend on numpy1 this way anyway, so that's fine. But that only helped a little. Now I get a compilation failure. The build error is: [853/1238] Compiling C++ object scipy/...1.so.p/src__fmm_core_write_coo_64.cpp. FAILED: [code=1] scipy/io/_fast_matrix_market/_fmm_core.cpython-311.so.p/src__fmm_core_write_coo_64.cpp.o c++ -Iscipy/io/_fast_matrix_market/_fmm_core.cpython-311.so.p -Iscipy/io/_fast_matrix_market -I../scipy/io/_fast_matrix_market -I../scipy/io/_fast_matrix_market/fast_matrix_market/include -I../../../../../../local/lib/python3.11/site-packages/numpy/core/include -I../scipy/io/_fast_matrix_market/fast_matrix_market/dependencies/fast_float/include -Iscipy/io/_fast_matrix_market/fast_matrix_market/dependencies/ryu -I../scipy/io/_fast_matrix_market/fast_matrix_market/dependencies/ryu -I/include -I/usr/local/include/python3.11 -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++17 -O3 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -DNPY_NO_DEPRECATED_API=NPY_1_9_API_VERSION -DFMM_SCIPY_PRUNE -DFMM_USE_FAST_FLOAT -DFMM_USE_RYU -DFMM_FROM_CHARS_INT_SUPPORTED -DFMM_TO_CHARS_INT_SUPPORTED -MD -MQ scipy/io/_fast_matrix_market/_fmm_core.cpython-311.so.p/src__fmm_core_write_coo_64.cpp.o -MF scipy/io/_fast_matrix_market/_fmm_core.cpython-311.so.p/src__fmm_core_write_coo_64.cpp.o.d -o scipy/io/_fast_matrix_market/_fmm_core.cpython-311.so.p/src__fmm_core_write_coo_64.cpp.o -c ../scipy/io/_fast_matrix_market/src/_fmm_core_write_coo_64.cpp In file included from ../scipy/io/_fast_matrix_market/src/_fmm_core_write_coo_64.cpp:5: ../scipy/io/_fast_matrix_market/src/_fmm_core.hpp:14:10: fatal error: 'pybind11/pybind11.h' file not found 14 | #include <pybind11/pybind11.h> | ^~~~~~~~~~~~~~~~~~~~~ 1 error generated. (the same problem is reported in several files if I build without setting MAKE_JOBS_UNSAFE) Yet my system has pybind11 installed, and /usr/local/include/pybind11/pybind11.h exists. from pkg info: py311-pybind11-3.0.1 Seamless interoperability between C++11 and Python pybind11-3.0.1 Seamless interoperability between C++11 and Python (cmake part) and ls -l /usr/local/include/pybind11/pybind11.h shows: -rw-r--r-- 1 root wheel 160679 Aug 22 2025 /usr/local/include/pybind11/pybind11.h Uname: FreeBSD xxxx.xx 14.3-STABLE FreeBSD 14.3-STABLE stable/14-n273238-c95f96dea30a GENERIC amd64 In /usr/ports, git describe shows: git describe 14.2-eol-19692-gcc704ef2c80e UPDATE: After reading a comment in 281470 about CMake maybe being a problem, I removed the "cmake part" of pybind11, which *removed* pybind11/pybind11.h. After that the py-scipy port compiled and installed without throwing this error about not being able to find the file. So this is an oddity introduced entirely by the presence of the pybind11 package. py-pybind11 is still needed. There's still something fishy about this port, but that's the workaround.
The differences between devel/pybind11 and devel/py-pybind11 primarily lie in where the headers are located. devel/pybind11 has them in the regular system hier(7); devel/py-pybind11 has them in the Python package hierarchy, ie site-packages, also including Python package metadata and a pybind11-config program to assist consumers in finding the headers outside the usual hier(7). The scipy build process in meson-python first queries for the pybind11 Python package, and later during the meson configure process does the header location get established. devel/pybind11 is harmless to this build process as long as the cmake port/package is not present in the environment. Unfortunately meson will prefer to use cmake for dependency detection over pkg-config or other methods like *-config programs, so it is important that, unless a dependency is only meant to be discoverable via cmake, that cmake is not present so meson can use the other methods. It bears repeating that these issues are entirely avoided with environment isolation like poudriere.
Or you can just add USES+=localbase as a workaround.
USES=localbase is incorrect. The needed includes are not located in the directories that USES=localbase adds to compiler flags. This is squarely about (presumably leftover from previous builds) cmake being present in an environment that it should not be in.