The mouse reference is a pointer. If it's NULL, the driver uses a default. If it's non-NULL, then it points to a function that the driver can call. That function will adjust the driver's calibration value. It could ask the user to adjust the pen; or, it could read a file that holds a value from a previous calibration.
Application writers can choose how it's done: a function that's provided by the library, a custom function, or nothing.
If the variable 'prefix' is defined then the builtin search paths are set to
$(prefix)/lib/cc65/... allowing to build binaries intended for installation.
Note that the library build still works with these binaries as it generally
overrides the builtin search paths by setting the CC65_HOME env var.
Originally I used the usual variables (like $(CC) and $(CFLAGS) ) but after
all this doesn't make sense as any predefined values and/or user defined
settings can only be wrong.
Occasionally dynamically drivers suffer from not being to refer to
content in the C library. Therefore I added a mechanism to allow
a C library for a certian target to define a symbol that will be
handed over to dynamic drivers for that target. Then the drivers
can use their refernce to that symbol to access content in the C
library.
The libraries build is prepared to work with binaries not part of the current
working tree. But in this case the default search path surely points to some
other working tree. Even the binaries in this working tree might have been
compiled with non-standard builtin search paths.
Anyway when building the libraries we want always to use the headers from
the current working tree. Therefore we want to set them explicitly. Instead
of setting all in all five paths on the command lines of ca65, cc65 and ld65 I
opted to just set the single environment variable.