[PD-dev] overriding "internals"
IOhannes m zmoelnig
zmoelnig at iem.at
Sat Nov 10 17:25:54 CET 2007
Hans-Christoph Steiner wrote:
>
> On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
>
>>
>> cyclone does something like this (it overrides already registered
>> externals, which - at this point - are not different from internals)
>>
>> it is basically looking whether the class-name is already registered,
>> and if so, overwrites the class-pointers.
>>
>> however, for this to work, you need first need to call a function in
>> your overriding new library.
>> therefore you will probably need something like a "library" (instead
>> of single, same-named externals)
>
> I'd rather not use a special mechanism, especially if it is not already
> widely used.
well you asked, i gave you an answer.
but then i probably have not read your original email as careful as i
have should.
>
>>> I was thinking of just breaking out the classes into their own
>>> files, then compiling things as a libdir. This is pretty easy for
>>> most of the objects, but I haven't gotten into the DSP classes yet,
>>> and I expect things will be more complicated there. And [list] too.
>>
>> funnily enough i have always been opposed when requesting that the
>> [list] objects get _proper_ names.
>
> Why? For example, [list append] will happily append a symbol to a
> float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
>
> The libtkwidget.so would be included in the libdir to make it a simple
> package.
so how do you convince the ldopen to look for the libtkwidget.so in your
libdir instead of whatever is configured in /etc/ld.so.conf?
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as
"a simple package".
i would really be interested in a solution for this.
mf.asdr
IOhannes
More information about the Pd-dev
mailing list