Do not build on the BSDs: hwinfo has no backend for them - #3
Conversation
hwinfo ships three backends and picks one in include/hwinfo/platform.h. The one it calls "unix" is really the Linux one - it reads /proc and /sys everywhere, src/linux/network.cpp includes <netpacket/packet.h> and filters getifaddrs() on AF_PACKET, and src/linux/ram.cpp asks sysconf() for _SC_AVPHYS_PAGES. None of that exists on FreeBSD, which has <net/if_dl.h> and AF_LINK for the first and the vm.stats.vm sysctls for the second. platform.h nevertheless keys that backend off __unix__, so FreeBSD selects it and those two files fail to compile: src/linux/network.cpp:8:10: fatal error: 'netpacket/packet.h' file not found src/linux/ram.cpp:29:37: error: use of undeclared identifier '_SC_AVPHYS_PAGES' Everything else in hwinfo does compile there, but it would only read paths that a FreeBSD system does not have, so shimming the two files would buy an add-on whose whole device tree is empty. The fix worth having is a real BSD backend upstream in lfreist/hwinfo; until then, skip the add-on. This add-on was the only thing keeping score from building on FreeBSD - the rest of the tree compiles and links there once it is out of the way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Verified in a FreeBSD 15.0 VM (same Before, Those 42 are the ones that do compile — the whole apple and windows backends compile to nothing there, and the rest of After: and The Ubuntu / Windows / JIT checks on this PR are red on |
This add-on is the single thing that stops
ossia/scorefrom compiling on FreeBSD. With it out of the way, the rest of the tree builds and links cleanly there.What is broken
hwinfo picks a backend in
include/hwinfo/platform.h:The backend it calls "unix" is really the Linux one — every file under
src/linux/reads/procand/sys, and two of them use interfaces that only exist on Linux:src/linux/network.cpp<netpacket/packet.h>,AF_PACKET<net/if_dl.h>,AF_LINKsrc/linux/ram.cppsysconf(_SC_AVPHYS_PAGES)sysctl vm.stats.vm.v_free_countFreeBSD defines
__unix__, so it selects that backend and those two files fail:Why skip rather than shim
I compiled every hwinfo source on FreeBSD 15.0 one by one — those two are the only failures, so a pair of shims in
hwinfo.cmakewould make it build. But it would not make it work: the files that do compile read/proc/cpuinfo,/proc/stat,/proc/meminfo,/sys/class/net,/sys/class/drm,/sys/block,/sys/class/power_supply,/sys/devices/virtual/dmi. None of those are there on a FreeBSD box, so the add-on would ship a device tree that is empty end to end.The fix worth having is a real BSD backend upstream in lfreist/hwinfo —
getifaddrs+AF_LINKfor the network side,sysctl(3)(hw.physmem,vm.stats.vm.*,hw.model,kern.disks,kern.osrelease) for the rest. That is a backend, not a shim, and it does not belong in this repository. Until it exists, do not build the add-on there.The change
One guard in
CMakeLists.txt, next to the existingEMSCRIPTENone:Nothing on Linux, macOS or Windows is touched —
CMAKE_SYSTEM_NAMEisLinux/Darwin/Windowsthere.How it was verified
In a FreeBSD 15.0 VM built from the same
vmactions/freebsd-builderimage the CI uses, with the 265 packages.github/workflows/bsd.ymlinstalls:c++ -std=c++20→ exactly the two errors above, nothing else;ci/freebsd.build.shof score with this add-on present and this patch applied → configures (score-addon-sysinfo: hwinfo has no FreeBSD backend, skipping), compiles and installs.Note that
ossia/score's FreeBSD job never noticed any of this:ci/freebsd.build.shexited 127 on its shebang and the workflow swallowed the status. That half is fixed in ossia/score#2213; this PR should land first, otherwise that one turns the job red.