[PD-dev] library finding it's own path?

[IOhannes m zmölnig]

martin.peach at sympatico.ca wrote:
>  >
>  > thanks for the hints, but this is even more "ugly" (no harm intended)
>  > than what i already have. i really want to be agnostic about which
>  > extension the library has (just image miller adds a new extension; or
>  > hans removes .l_i386 from PdX and i will actually find the wrong binary)
>  >
> 
> Well it's the same 'ugly' code that Pd itself uses. I simply copied the 
> extension list from Pd source. 

you got me wrong.
i know that it is copied from Pd sources and i have no problem with how 
Pd implements this.
however, i want to find out where Pd got the file from, and just trying 
to do the same as (a specific version of) Pd and hope to end up with the 
same result is what i consider "ugly".
(if i want to know what you get by multiplying 54234*6533 then it is no 
use to calculate it myself; either of us can make an error in the 
calculation and then my result will tell me nothing about yours)

> I guess you could just access the list 
> directly and then not worry about it changing in the future. The code 
> for [which] tries all possible extensions for the current OS and opens 
> the first one that exists. Pd does the same thing, or at least the 
> version in svn does. 

that is the problem.
when running [which] with an older version of Pd (say: 0.39) and you 
have concurrent .pd_linux and .l_i386 lying around, then you might 
eventually get the wrong result (as you find .l_i386 for which Pd-0.39 
doesn't care at all)

> Probably if the relevant functions were exposed in 
> m_pd.h they could all be used in situ.

yep, this is along the lines i was thinking.
my approach with querying the class about it's "externdir" member is 
very much what i want (and do), it's only that this can only be found in 
private headers. (resulting in both compile-time and compatibility 
problems).
you could have a look at my code at 
https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem/src/Base/GemSetup.cpp


i was wondering whether i have overlooked a way to query private members 
of a class.
probably we can tell miller into something like
int class_getmember(t_class*c, t_symbol*id, t_atom*result);
which would allow the developers to access existing private members (the 
funtion would return an error-code if the "id" did not name an existing 
member (or at least one that Pd knows about)

this seems to be more elegant than adding a bunch of functions like
char* class_getname(t_class*c)


mfgasdr
IOhannes