flua: Move to a new flua package

flua is a standalone third-party component that deserves its own
package. In particular, this means things can use flua without
having to depend on FreeBSD-utilitie

flua: Move to a new flua package

flua is a standalone third-party component that deserves its own
package. In particular, this means things can use flua without
having to depend on FreeBSD-utilities, which will be useful as
more base utilities use flua.

This saves ~500kB in FreeBSD-utilities for systems which don't
need flua.

MFC after: 3 days
Reviewed by: kevans
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53161

show more ...

flua: move lposix back into flua for now

The real luaposix is structured differently, and our builtin version
tends to model that in its own special way. Build it back in until we
get the shlib mod

flua: move lposix back into flua for now

The real luaposix is structured differently, and our builtin version
tends to model that in its own special way. Build it back in until we
get the shlib model just right to unbreak nuageinit, among other things.

This is a partial revert of the below-referenced commit; the other two
modules are simple, though, and were accurately split out.

Reported by: markj
Fixes: b11a5709ec2b6 ("flua: kick out the remaining builtin modules")

show more ...

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.

Revert "flua: don't build libjail into the bootstrap flua"

This reverts commit 31320402472394af57eb3a36bee7f944117ca0ed, because
bootstrap flua is about to get backed out.

flua: don't build libjail into the bootstrap flua

Other systems don't have jail support, and we won't be using it anyways.

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

lyaml: vendor import lua bindings for libyaml

flua: Add minimal man page

Flua is a minimal Lua interpreter integrated into the FreeBSD base
system. It is intended for internal use and is not designed for
general-purpose scripting or use by thi

flua: Add minimal man page

Flua is a minimal Lua interpreter integrated into the FreeBSD base
system. It is intended for internal use and is not designed for
general-purpose scripting or use by third-party applications, and was
originally intentionally undocumented.

There have been questions about its purpose, and questions about the
available functionality from internal users, so provide a minimal man
page including these details.

Reviewed by: kevans, Isaac Freund <ifreund@freebsdfoundation.org>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49835

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: make the ucl module a dynamic module

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46569

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

flua: add fbsd module

This module is bundled into flua, it only provides for now the exec
function. The point of the function is to be able to execute a program
without actually executing a shell.

flua: add fbsd module

This module is bundled into flua, it only provides for now the exec
function. The point of the function is to be able to execute a program
without actually executing a shell.

to use it:
fbsd.exec({"id", "bapt"})

Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41840

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r364082 through r364250.

Properly disable LUA_USE_DLOPEN for bootstrap flua

flua does have some specific bits that will include luaconf.h, but the
definition of LUA_USE_DLOPEN for those won't matter. This belongs in liblua

Properly disable LUA_USE_DLOPEN for bootstrap flua

flua does have some specific bits that will include luaconf.h, but the
definition of LUA_USE_DLOPEN for those won't matter. This belongs in liblua
instead.

To expand on my previous commit, which was a little sparse with details,
it's not really safe to allow LUA_USE_DLOPEN with host lib paths being used.
The host system could have an entirely different lua version and this could
cause us to crash and burn.

If we want to revive this later, we need to make sure to define c module
paths inside OBJDIR that are compiled against whatever version we've
bootstrapped.

Pointy hat: kevans

show more ...

flua: don't allow dlopen, et al., for bootstrap flua

There are some logistics issues that need to be sorted out here before we
can actually allow this to work.

flua: support "require" for binary objects in the base system

Export symbols from flua, and enable dlopen.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2

flua: support "require" for binary objects in the base system

Export symbols from flua, and enable dlopen.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26059

show more ...

flua: add ucl library

libucl comes with a Lua library binding. Build it into flua.

This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the

flua: add ucl library

libucl comes with a Lua library binding. Build it into flua.

This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the following script will detect the format of
an object written to stdin as one of UCL config, JSON, or YAML and write it to
stdout as pretty-printed JSON:

local ucl = require('ucl')
local parser = ucl.parser()
parser:parse_string(io.read('*a'))
local obj = parser:get_object()
print(ucl.to_format(obj, 'json'))

Reviewed by: kevans, pstef
Approved by: mmacy (mentor)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25009

show more ...

flua: follow-up to r359453, don't bother with libedit in bootstrap

The bootstrap flua should not be used for REPL-like activities; exclude it
to save the dependency on libedit and not waste time wit

flua: follow-up to r359453, don't bother with libedit in bootstrap

The bootstrap flua should not be used for REPL-like activities; exclude it
to save the dependency on libedit and not waste time with it.

X-MFC-With: r359453

show more ...

flua: enable readline bits, courtesy of libedit

This is a nicer experience when attempting to run ad-hoc lua bits in the
flua REPL.

PR: 245121
MFC after: 1 week