On Nov 10, 2007, at 11:25 AM, IOhannes m zmoelnig wrote: > 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.
No problem, I am just discussing how I think it should be done. >>>> 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? Ok, but you can use a different word. Why do these things need a special syntax of a meta object and then another selector? Also consider [trim]. If [list trim] will trim "symbol" from a symbol message, then it's not doing anything with lists. >> 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. Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf. .hc ------------------------------------------------------------------------ ---- News is what people want to keep hidden and everything else is publicity. - Bill Moyers _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
