cortav  Diff

+ build | [`build] |  the directory where generated objects will be placed; useful for out-of-tree builds
+ bin-prefix | [`[$$prefix]/bin] | directory to install the executables to"
+ default-format-flags | [`-m html:width 35em] | a list of flags that will be passed by the viewer script to [`cortav] when generating a html fille

the following targets are supplied to automate the build:
* [`install] builds everything, installs the bytecode-executable and the viewer script to [$$bin_prefix], and registers the viewer script with XDG
* [`install-bin] is like [`install] but installs the binary version instead of the bytecode one
* [`excise] deletes everything installed and deregisters the file handlers (note that the same variables must be passed to [`exicse] as were passed to [`install]!)
* [`clean] deletes build artifacts from the [$$build] directory like it was never there
* [`wipe] is equivalent to [`$ make excise && make clean]

if you don't want to install [`cortav], you can just run [`$ make] without arguments to build the executable.

there are two different ways of building the driver. one is to generate a bytecode file that can be executed directly as a script. this is the most straightforward method, and requires only [`lua] and [`luac]. however, it has several substantial downsides: because it's only a bytecode file, it requires the [`lua] interpreter to run -- and in some environments, the security characteristics of the [`lua] interpreter may make this undesirable. it also must hardcode the path to the lua interpreter (though admittedly this is easy enough to fix if you copy it to another machine of the same architecture). [`lua] is not an entirely predictable environment, as it is controlled by environment variables and may hypothetically do things like load default libraries or alter paths in ways that disrupt the workings of [`cortav]. finally, because the bytecode file is not a binary executable, it cannot directly be given enhanced capabilities on unix-like systems through filesystem metadata -- SUID and caps will be ignored by the kernel. while this is of no importance in ordinary operation, there are niche cases where this could be troublesome.

+ build | [`build] |  the directory where generated objects will be placed; useful for out-of-tree builds
+ bin-prefix | [`[$$prefix]/bin] | directory to install the executables to"
+ default-format-flags | [`-m html:width 35em] | a list of flags that will be passed by the viewer script to [`cortav] when generating a html fille

the following targets are supplied to automate the build:
* [`install] builds everything, installs the bytecode-executable and the viewer script to [$$bin_prefix], and registers the viewer script with XDG
* [`install-bin] is like [`install] but installs the binary version instead of the bytecode one
* [`excise] deletes everything installed and deregisters the file handlers (note that the same variables must be passed to [`excise] as were passed to [`install]!)
* [`clean] deletes build artifacts from the [$$build] directory like it was never there
* [`wipe] is equivalent to [`$ make excise && make clean]

if you don't want to install [`cortav], you can just run [`$ make] without arguments to build the executable.

there are two different ways of building the driver. one is to generate a bytecode file that can be executed directly as a script. this is the most straightforward method, and requires only [`lua] and [`luac]. however, it has several substantial downsides: because it's only a bytecode file, it requires the [`lua] interpreter to run -- and in some environments, the security characteristics of the [`lua] interpreter may make this undesirable. it also must hardcode the path to the lua interpreter (though admittedly this is easy enough to fix if you copy it to another machine of the same architecture). [`lua] is not an entirely predictable environment, as it is controlled by environment variables and may hypothetically do things like load default libraries or alter paths in ways that disrupt the workings of [`cortav]. finally, because the bytecode file is not a binary executable, it cannot directly be given enhanced capabilities on unix-like systems through filesystem metadata -- SUID and caps will be ignored by the kernel. while this is of no importance in ordinary operation, there are niche cases where this could be troublesome.