Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux would only include shared code, but for this case, it would also include the >~ class, etc.
i guess you meant to name it either "audiomath/libaudiomath.so" (or .dll or .dylib) or "audiomath/audiomath.pd_linux".
Perhaps audiomath/libaudiomath.so makes the most sense so that it can't be loaded by Pd as an objectclass. But I am guessing.
the question is why you would want to enforce Pd not being able to load this library. at the worst this would allow to mix abstractions, single-object-binaries, multi-object-binaries and shared-code dylibs into a single "bundle" (libdir-like directory defining a library)
the only reason i see to create an explicit mechanism to prevent Pd from loadinga file as an object-class is a notorious aversion against multiboject-binaries.
it's ok for me if someone doesn't like these. it's not ok for me declaring war on them.
i admit that currently all C-code is considered "shared" (that is: there is no "list2symbol.pd_linux"), but once you start blurring the two worlds it get's blurry anyhow (and "l2s" and "list2symbol" share about 100% of their code anyhow)
I like having each objectclass as its own file.
i know
Then only the code that is in use will be loaded into memory. linking everything together into one zexy.pd_linux means the whole thing is loaded into memory, no?
obviously. but you are surely aware that you cannot avoid people doing this with shared libs (that cannot be loaded directly by Pd) as well.
so again, the only reason to make this explicit is because to throw feeble hurdles on the path of freedom of a developer.
<trying to turn pathos mode off>
i would also like to have Pd's loading mechanism modified so that it _temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a library with external dependencies (without having to link them statically)
I am sure you don't mean to do this on GNU/Linux, right?
yes i want to do this on all platforms.
I take it you mean like including a .dylib in the Gem folder?
but i am not talking about including libGL.so with Gem.
it is really something along the lines of your proposal on "audiomath/libaudiomath.so".
Kind of like what I do with Pd-extended and the Fink dylibs? That is not a great system. I think due to the limitations of the Mac OS X shared lib loading, it would be painful. Basically, AFAIK, a .dylib in Mac OS X must have its path hard-coded in the file. Otherwise, you have to load it manually with a direct call to dlopen.
but the path can be relative, no?
I don't remember the details in Windows, I think that it already checks "." for .dlls by default.
this is how i remember it as well.
fgmasdr IOhannes