Skip to content
CEagle

LibLoad libraries

A library project publishes two things from one build: the appvar the calculator loads, and the developer archive other people link against.

A LibLoad library is code other programs call into. On the calculator it is an appvar that LibLoad loads at runtime; on a developer's machine it is a stub the linker resolves against, plus headers.

CEagle publishes both from one build.

What a release ships#

NAME.8xv/d/<slug>/raw

The appvar LibLoad reads on the calculator. It is the program body, downloaded like any other program, so Swoop installs it exactly the same way.

slug-version.zip/d/<slug>/lib

The developer archive: the appvar, the .lib stub and the public headers, flat and named by their base names. This is what someone linking against the library downloads.

Flight stages that archive itself from the files the manifest names, so both build modes below leave exactly the same thing behind.

Two ways to build one#

Built herelibify, the default

Describe the sources and ce-libify does the rest. Flight writes the build command from your manifest, so there is nothing to keep in sync.

Read on
Built by the repositorycustom

For a library that has outgrown a generated command: an unusual layout, a generator step, its own assembly. Flight runs your command and collects what you name.

Read on

Either way the release records which mode produced it, and the Roost page says so.

Built here#

The default. Describe the sources:

[library]
mode = "libify"
name = "DEMO"
version = 1
src = "src"
include = "."
exports = "exports.txt"
headers = ["demo.h"]
optimize = "-Oz"

Flight writes the ce-libify build command from that. The build command is therefore not read here, and setting one is an error rather than a silent no-op. The outputs are always bin/NAME.8xv and bin/NAME.lib.

Setting up ce-libify

Layout, the export table, installing it locally, and the constraints that will bite you.

Read on

Built by the repository#

[library]
mode = "custom"
name = "DEMO"
appvar = "bin/DEMO.8xv"
stub = "bin/DEMO.lib"
headers = ["include/demo.h"]

[build]
command = "make lib"

A build command is required, and the appvar and stub paths default to bin/NAME.8xv and bin/NAME.lib. Nothing about ce-libify applies: the build may use it, or not.

A build that ships no stub says so with an explicit empty string. The library still loads on the calculator; nothing else can link against it.

stub = ""

The name#

[library] name is the LibLoad name, and it is a different thing from the project address.

A valid LibLoad name
length1 to 8 charactersRequired
first charactera letterRequired
alphabetA-Z 0-9Required

Capitals and digits. Lowercase input is normalised up.

It is what LibLoad resolves at runtime and what the linker looks for, so like the address it is not something to change casually once anything depends on it.

Being depended on#

A program names the libraries it needs by address, not by LibLoad name, and so does a library that links against another one:

[program]
depends = ["demo-library"]

Roost then flattens the graph for clients, so Swoop asks once and writes everything in order.

Dependencies

The rules, the limits, and what Swoop does with the answer.

Read on

Linking against one#

Download the developer archive and put its pieces where the toolchain looks:

curl -sLO https://roost.ceagle.cc/d/demo-library/lib
unzip demo-library-1.0.0.zip
cp DEMO.lib "$CEDEV/lib/libload/"
cp demo.h "$CEDEV/include/"

Then send DEMO.8xv to the calculator, or let Swoop do it by declaring the dependency.

Categories#

A library with no categories in its manifest lands in libs rather than other, which is the one place where the default depends on the project language.

CEagle documentation