flua: kick out the remaining builtin modules

Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always build

flua: kick out the remaining builtin modules

Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.

Adjust the stand build now that these three libs have their own new
homes.

Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891

show more ...

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 ...

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 ...

Revert "flua: kick out the remaining builtin modules"

This reverts commit 80ada959004c4386880e47b11618f8abfc2d80e1, because
bootstrap flua is about to get backed out.

flua: kick out the remaining builtin modules

Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always build

flua: kick out the remaining builtin modules

Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.

Adjust the stand build now that these three libs have their own new
homes.

Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891

show more ...

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.

Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51890

show more ...

flua: move modules source into the main source directory

Follow the path of what is done with bsnmp, build the modules along
with the main binary, this allows to build the modules at a moment
where

flua: move modules source into the main source directory

Follow the path of what is done with bsnmp, build the modules along
with the main binary, this allows to build the modules at a moment
where all needed libraries are already built and available in the
linker path instead of having to declare all the libraries which a
flua module will be linked to in _prebuild_libs.

Discused with: markj
Reviewed by: markj, jrtc27, kevans, imp
Accepted by: kevans, imp
Differential Revision: https://reviews.freebsd.org/D46610

show more ...

flua: Add hash module

Add lua bindings to hashing functions. sha256 is available. sha256.new
craetes a new object. sha256.update updates the digest. sha256.digest
returns the digest as a binary stri

flua: Add hash module

Add lua bindings to hashing functions. sha256 is available. sha256.new
craetes a new object. sha256.update updates the digest. sha256.digest
returns the digest as a binary string and resets the
context. sha256.hexdigest returns the digest as a string of hex digits
and then resets the cotnext.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D43872

show more ...