On Apr 29, 2011, at 10:04 AM, august wrote:
Windows and Mac OS X both use the path of the executable for
finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this
on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to
be sorted out.Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
That part of Windows linking I don't know, so the thing to do is to find whether there is a way to add to the DLL load path, then make readanysf~ do that. That's probably a single function call. Otherwise, people will need to install the DLLs into pd\bin or \Windows\system32.
.hc
I guess what I am asking, is that now that it exists for all
platforms, what in your opinion is the best strategy for including it in pd-extended? Or, is it already included?Are there any other externals that package .dll's and .so files in pd-extended? Maybe we can look at this tomorrow in LA (if I make it).
It would be good to first get out some standalone builds and work out
the kinks. Then you'll have a way to make standalone builds on your
own release schedule. Once its in Pd-extended, your release schedule
will be entirely tied to Pd-extended's release schedule. From what
I've seen, that only really works for very active devs or rarely
changing libraries. I can't take on any more maintenance, I'm already
well overloaded with what I've got.
.hc
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)