| 151bd351 | 04-Oct-2025 |
Kyle Evans <kevans@FreeBSD.org> |
flua: support our flua modules in the bootstrap flua
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
canno
flua: support our flua modules in the bootstrap flua
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant. We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.
Reviewed by: bapt, emaste (both previous version)
Differential Revision: https://reviews.freebsd.org/D51890
show more ...
|
| bbef1c72 | 04-Oct-2025 |
Kyle Evans <kevans@FreeBSD.org> |
Revert "flua: support our flua modules in the bootstrap flua"
This reverts commit 1953a12ee2cde1afacb3e3f7612d89695c96e04f, because it
cannot work at all on macOS without more work, at a minimum. W
Revert "flua: support our flua modules in the bootstrap flua"
This reverts commit 1953a12ee2cde1afacb3e3f7612d89695c96e04f, because it
cannot work at all on macOS without more work, at a minimum. We use
linker sets for module discovery, but we don't have a version of this
that works for mach-o at the moment.
show more ...
|
| 3f0e1092 | 09-Jul-2025 |
Kyle Evans <kevans@FreeBSD.org> |
flua: fbsd: allow stdout to be captured for exec() processes
This allows us to do things like:
```
local fp = assert(fbsd.exec({"ls", "-l"}, true))
local fpout = assert(fp:stdout())
while true do
flua: fbsd: allow stdout to be captured for exec() processes
This allows us to do things like:
```
local fp = assert(fbsd.exec({"ls", "-l"}, true))
local fpout = assert(fp:stdout())
while true do
local line = fpout:read("l")
if not line then break end
print("Read: " .. line)
end
fp:close()
```
The makeman lua rewrite will use it to capture `make showconfig` output
for processing.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50539
show more ...
|
| 6a2c624b | 09-Jul-2025 |
Kyle Evans <kevans@FreeBSD.org> |
flua: fbsd: return a process handle to operate on when we exec()
This gives us some way to be able to write to stdin if we want to, or
as a future improvement, will allow us to extract stdout from t
flua: fbsd: return a process handle to operate on when we exec()
This gives us some way to be able to write to stdin if we want to, or
as a future improvement, will allow us to extract stdout from the
process. The handle is setup to close and waitpid() on close/gc so that
existing users wouldn't necessarily leak for the lifetime of the script
if they weren't adopted to the new model.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50538
show more ...
|