tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Request for MacOS test and import: wip/stirmake => devel/stirmake
Hello,
I think wip/stirmake is now as far complete as I can make it. It has
been tested to be fully functional on all the major pkgsrc platforms
with the exception of MINIX3 (installation of MINIX hangs in my KVM, but
since MINIX3 is discontinued and the last release is 12 years old, it is
probably acceptable to leave stirmake on MINIX untested due to lack of
working virtual machine) and MacOS (don't have hardware).
Stirmake is a fast build tool intended to make it easy to create
recursive (and by this I don't mean recursively calling sub-Stirmake
processes) build systems that may have submodules, in a manner that
isn't harmful according to the famous paper "Recursive Make Considered
Harmful" by Peter Miller. Recursive nested scoping is supported, so if
the parent Stirfile sets $CFLAGS, and a child Stirfile modifies it, the
modifications are visible to the grandchildren but not to the parent. It
is fully programmable in the embedded Amyplan programming language and
with Lua if compiled with it.
Stirmake, being a build tool, has the potential to unlock addition of
several other possible packages that use it, to pkgsrc. Stirmake itself
is built in the pkgsrc package using a bootstrap script, to allow it to
be built without requiring itself to build itself. In the default
configuration, there are intentionally zero dependencies, to allow
making building and installing it as lightweight as possible. Building
it takes 20 seconds, in comparison to building devel/ninja-build which
installs everything and the kitchensink including cmake (ugh!) and takes
2500 seconds on a machine where Python was already installed, just to
have a low-level build tool that isn't usable without something like
meson.
The testing on MacOS isn't full because I don't have access to Mac
hardware. The prices of new 2026 Mac Mini start at 1100 euros, and
since Apple supports hardware for only about 6-7 years, the annual cost
is quite high. An older model such as from ~2023 is false economy:
support can be expected for only about 3-4 years while not even halving
the price.
So I have done everything I can without spending the 1100 euros to
ensure that it should work well on MacOS. I have cross-compiled it using
"zig cc" with MacOS amd64 and arm64 as the targets, and it compiles. I
have tested the amd64 Mac binary on "darling" MacOS emulator, and it
runs and works just fine. Unfortunately, my emulator has network
connectivity issues I couldn't solve so using Homebrew or pkgsrc on it
would be very tricky.
But, it still could be nice if someone with Mac access could test the
package. It runs the standard unit test suite with "make test", which
has worked for me on all of the BSDs, Linux and OmniOS.
An alternative to this could be simply importing it as-is, relying on my
comprehensive preparations to ensure MacOS compatibility, and in the
unlikely case that it doesn't build, the bulk build logs would probably
allow solving the issue remotely.
BR, Juha-Matti
Home |
Main Index |
Thread Index |
Old Index