falpack(1)

📦 version 0-unstable-2023-11, in nixos 26.05

💖 falpack(1) — the falcon application packaging tool 💖

okay bestie, welcome to falpack(1), aka the Falcon User Manuals entry for the falcon application packaging tool. this is the page where you learn how to shove your whole falcon app into a folder and have it, like, actually run somewhere else. no cap. ✨

🌸 SYNOPSIS 🌸

falpak [options] main_script

(yes, it says falpak up there — that's the page's own spelling, we're keeping it exactly as-is, iykyk 🫶)

🦋 DESCRIPTION 🦋

so the tea is: falpack is a command line tool that copies all the modules and other dependencies your standalone falcon application needs into a target directory. that's the whole vibe check. 💅

it can also copy the system files you need to run the app — which makes the final application totally stand-alone — or it can just stash the needed modules so that a local falcon installation can be used to run the application. your choice, main character energy either way ✨

falpack searches for special attributes in the parsed modules so it can store resource data files that an application may require. it copies needed internationalization translation tables too, and eventually compiles sources into binary .fam modules. it can also remove sources from the final installation, so that pre-compiled applications only can be shipped. and finally, it creates a script that can be used to run the application with a "single click" operation on the host platform. obsessed. 🔥

system relevant modules (as i.e. feathers or system-wide installed modules) are also stored together with the application. 🐚

anyhow, installation of falcon system files (which include feather modules) is optional. not mandatory, just a slay little extra.

system files get copied into a fake root subdirectory (normally called _system). all the modules that aren't lying under the same directory of the application "main script" or in deeper trees are considered "system-wide" installed, and it is supposed that the script accesses them via the -L option or via the FALCON_LOAD_PATH environment variable. so those ones get stored in the system directory and a directory tree is re-created, meaning that the simple addition of the fake root to the load path (i.e. falcon -L _system) is enough to access all of them. literally so clean. 🧚

this method allows the application to access modules by logical name and by filename, because the filename is made relative to the load path. BUT 💀 — modules loaded with absolute filenames must be separately installed on the target system so that their position matches the required absolute path. no shortcuts there, sorry bestie.

🎀 OPTIONS 🎀

  • -b <module>` — blacklists this module (by module name). using this option, it's possible to prevent default action on the given module (copy into the application tree or the fake root tree). and you can specify more blacklisted modules by repeating this option as many times as your heart desires 💅
  • --bin <dir>** — specify the directory where the falcon binary resides. useful if falpackis required to read an interpreter from a non-default installation, or if it can't find it. **NOTE:**falpack` uses falcon build environment settings. if used under the build environment, it will copy files from the active build tree, **ignoring system wide installations. 👀
  • *-e *<enc>** — source files encoding. in case the source file text encoding is different from the system default encoding, the module loader may detect syntax errors or fail to load the sources; also, if .fam` generation is required, the strings in the pre-compiled modules. (that's the sentence as the page gives it, fr fr — we're not editing it 🙈)
  • -h — usage help. a short in-line summary of options. the "help me help you" button 🫶
  • --lib <dir>** — specify the directory where the falcon engine dynamic link library resides. useful if falpackis required to read an interpreter from a non-default installation, or if it can't find it. **NOTE:**falpack` uses falcon build environment settings. if used under the build environment, it will copy files from the active build tree, **ignoring system wide installations. ⭐
  • -L <dir>** — redefine FALCON_LOAD_PATH. use this in case the main module needs a special load path that isn't the system default or the one stored in the FALCON_LOAD_PATH` environment variable. *notice that this setting overwrites system and environment variable settings. also notice that this load path is intended for *local loading and compiling of the modules in the application — the modules are then arranged so that this setting is not needed in the final application. so it's like, a temporary vibe ✨
  • -M — pack also pre-compiled modules. if given, this option will cause .fam modules to be stored beside their source files (.fal or .ftd). it is incompatible with the -s option. pick a lane bestie 😭
  • -P <dir>` — save the package in this directory. by default, the package is stored in a directory with the same name as the main module (its extension stripped), under the current work directory. this option overrides the default and allows you to store the package at an arbitrary location. 🎁
  • *-r *<name>** — install *<name>* instead of "falcon"as interpreter. useful in case only pre-compiled modules are packaged, wherefalrunmay be employed, or in case of a special system-specific interpreter build, as withsdl_falcon` MacOSX framework compatible interpreter. 💫
  • *-R *<dir>** — change the fake root for system data into *<dir>*. if the default name for storage of system specific apparels (as binary modules, falcon engine library etc.), which is "_system"`, is not satisfactory, it can be overridden through this option. 💜
  • -s — strip sources. using this option, source falcon files are not copied in the package; only the pre-compiled bytecode .fam modules are stored. shipping-only-bytes energy 🔥
  • -S — do not store system files. prevents copying of the falcon interpreter, falcon engine dynamic library and feather modules. keep it light 🌈
  • -v — prints version and exit.
  • -V — verbose mode. prints verbose messages of what falpack is doing. the "tell me everything" option, we love a narrator 🗣️

🌟 SPECIAL ATTRIBUTES 🌟

falpack automatically packages needed ancillary files required by modules, like the translation table files (.ftr). but hold on — the modules may specify other files to be included through a set of special attributes, which are interpreted by falpack as it loads and analyzes them. 👑

💖 resources

this attribute can indicate a list of resources that should be copied together with the module. the attribute needs to be a string, and different resources can be separated through a semi comma (;). it's possible also to specify file masks using the "*.ext" pattern; whole subdirectories can be stored using the "dir/*" pattern. please notice that this attribute doesn't work recursively — to include sub-directories in resource directories, specify all of them. for example:

resources: "images/*; images/icons/*"

🐚 plugins

similar to the resources attribute, the plugins attribute indicates a single module or a directory containing more modules that may be used by the applications as dynamic plugins. differently from the data considered in the resources attribute, the files indicated in the plugins attribute are loaded by the loader, and their dependencies, if any, are further resolved and become part of the installed application. also, they are treated as any other module in any respect — for example, associated translation files are copied, and in case falpack is required to strip sources, only the pre-compiled .fam modules will be saved. 🦋

it is possible to store all the modules found in a certain directory using the "*" wildcard.

similarly to the resources attribute, the plugins attribute doesn't descend recursively in sub-directories; to include other modules laying below the required directory, that subdirectory must be explicitly specified, as in this example:

plugins: "output/*; output/helpers/*"

🌈 dynlib

this attribute stores one or more system dynamic library needed for the falcon module to run. depending on the host system, the target location may be in the fake root directory or besides the module (depending on how the system module loader tries to find the modules). more dependencies may be separated with a semi comma (;). 🧚

💀 BUGS 💀

relative paths are not jailed. if the resources attribute or the relative path of a loaded module indicates a position above the main script directory or above any position in the FALCON_LOAD_PATH specification, the files may be copied outside the target package location. be careful when writing the application you want to package, so that all the needed files can be reached at the same level as or below the main script, or at the same level as or below directories in the load path. this is the realest warning on the page, please read it twice 🙈

at the moment, it's quite complex to create cross platform packages (except for script-only applications which use a local falcon installation to run). it is planned to provide this support in future via the ability to download pre-compiled modules from a central repository. future update pending, we'll wait 💅

in this version, the dynlib attribute is not working for MacOSX style framework libraries. however, it will work for MacOSX dylib that can be found via the ldd command. 😭

👑 AUTHOR 👑

Giancarlo Niccolai <gc@falconpl.org>

🌸 SEE ALSO 🌸

falcon(1) falrun(1)

🎀 LICENSE 🎀

this document is released under the "GNU Free Documentation License, version 1.2". on Debian systems, the complete text of the Free Documentation License, version 1.2, can be found in /usr/share/common-licenses/. 📜

and that's the whole page, bestie — brought to you by the Falcon toolset, dated January 2010, filed under falpack(1). go forth and package something iconic 💅✨🫶

📦 where this page comes from