[PD-dev] setup() for hex loader

Hans-Christoph Steiner hans at eds.org
Wed May 28 15:37:52 CEST 2008


On May 28, 2008, at 1:28 PM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> Hey,
>> Just a thought here, I am currently porting a Max object to Pd  
>> and  just saw that the setup is called main().  So how about  
>> making it  possible to just use setup() as the function name?
>
> if i/you remember correctly, we have been talking about this at the  
> LAC.
> miller has some reservations against it which i think are invalid.

I only vaguely remember...

> afaik, the point against this is that we would have function name  
> clashes.
> obviously this is not a problem, as it works in max, in ftm4pd  
> (where i chose "ftm_main()" as the setupfunction for _all_  
> externals) and in most other plugin APIs.
>
> it becomes more problematic if we are dealing with multi-object  
> libraries rather than single-object externals: in this case we get  
> real nameclashes.
> to solve this one would have to either discard multi-object  
> libraries or inform the preprocessor on whether we want a library  
> or an external.

I think you can guess which one I think is good ;)  the multi- 
objectclass library file format seems to cause a lot more problems  
than it solves.

> then i think that "main(void)" is really the worst name they could  
> have thought of, as it clashes with "main(int argc, char**argv)".
> i would much more prefer a name like "pdsetup(void)"

I agree, pdsetup() works for me.

> all this could be resolved very simple by not having to explicitely  
> call a setup-function but by using the automatic function execution  
> at load-time (on gcc this is "__attribute__ ((constructor))", on M 
> $VC there are other ways...)
> the only drawback i see here is that you don't have control about  
> which function is executed first.

We could also switch to gcc on Windows, then we wouldn't have to work  
about M$VC oddness, unless someone really wants to.  gcc was been  
building Pd-extended for years now.

> finally, i don't know why this should be embedded into hexloader.
> hexloader currently does some clever recursive calling of other  
> loaders in order to be able to use it not only for C-externals but  
> also for lua, python,...
> therefore you would just have to write a "main loader" that calls  
> "main()" (or whatever) for external initialization.
> once you have loaded both the "main loader" and the "hexloader", Pd  
> will magically call the "main()" function in your  
> "here0x2d0x3ethere.l_i386"

Sure, makes sense to be system-wide.  I don't really have a good  
grasp on the implementation details, how hard would it be to add this  
to Pd?

.hc

>
>
> mfga.sdr
> IOhannes




------------------------------------------------------------------------ 
----

                             kill your television






More information about the Pd-dev mailing list