[PD-dev] linking in the heat

[Krzysztof Czaja]

hi all,

it is so hot here, thinking is so hard and painful... are there
cooler places on earth, where pd-dev people live?

...say, we have 150 classes using some amount of a common code.
The size of this common code is rather small -- close to the
average size of one class' code, or possibly 2 or 3 classes.
Some of the options are:

1. All classes, and the common code, are statically linked in
a one monolithic library.

2. Each class is kept as a separate external, linked with the
common code (which means: there are as many common code copies,
as the number of externals containing it, and loaded during
a Pd session).

3. The common code is linked dynamically, and it has to be loaded
prior to any of the classes (using an explicit -lib option).

4. Class names are prefixed with a library name, causing Pd to
load the library with both the common code, and the classes
(a feature not yet available, but already discussed on pd-list).

5. Like 4., but the library contains only the common code -- its
setup routine has to know what particular class is demanded, and
how to load it.

6. Each class uses a tiny ``stub code'', possibly a part of
a future Pd api, which somehow checks if the common code is
already loaded (currently it might be done by checking if
something 'familiar' is bound to a particular symbol).  If not,
it loads the library, and obtains a set of pointers to the
functions in the common code.

Are there other options?  Which option is best?

Btw, perhaps due to my mind melting in the heat, I somehow tend to
like the method 6 (if only it was a part of Pd api...)

Btw, options 4/5 cannot be applied in case of the cyclone library.
They might be in case of xeq or vexing (currently both are using
a modified version of the first method, while a cyclone user has
to choose between options 1 and 2).

Btw, there are not as many classes in cyclone (yet:-?) just a bit
over 40, but it keeps growing...

Krzysztof