Overview
Comment: | fix typo |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
c30f235b931d1814d0ecdb7774ae18cf |
User & Date: | lexi on 2022-09-05 20:46:49 |
Other Links: | manifest | tags |
Context
2022-09-08
| ||
23:37 | progress on resources + block macros; fix toc bug; add uri, fetch scaffolding, and b64e to sirsem check-in: 3ee2195d4f user: lexi tags: trunk | |
2022-09-05
| ||
20:46 | fix typo check-in: c30f235b93 user: lexi tags: trunk | |
20:15 | cleanup check-in: e551f71321 user: lexi tags: trunk | |
Changes
Modified cortav.ct from [1f89ec5932] to [99aafd4711].
764 764 + build | [`build] | the directory where generated objects will be placed; useful for out-of-tree builds 765 765 + bin-prefix | [`[$$prefix]/bin] | directory to install the executables to" 766 766 + 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 767 767 768 768 the following targets are supplied to automate the build: 769 769 * [`install] builds everything, installs the bytecode-executable and the viewer script to [$$bin_prefix], and registers the viewer script with XDG 770 770 * [`install-bin] is like [`install] but installs the binary version instead of the bytecode one 771 -* [`excise] deletes everything installed and deregisters the file handlers (note that the same variables must be passed to [`exicse] as were passed to [`install]!) 771 +* [`excise] deletes everything installed and deregisters the file handlers (note that the same variables must be passed to [`excise] as were passed to [`install]!) 772 772 * [`clean] deletes build artifacts from the [$$build] directory like it was never there 773 773 * [`wipe] is equivalent to [`$ make excise && make clean] 774 774 775 775 if you don't want to install [`cortav], you can just run [`$ make] without arguments to build the executable. 776 776 777 777 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. 778 778