> that allows it to be built both as a single binary *or* with one class per binary.
ah, of course that makes sense.
> with multi-binary style I can do [declare -lib foo/bar] whereas with the single-binary style that won't work.
I'm not sure I understand. Can give an example?
Gesendet: Sonntag, 12. Mai 2019 um 16:51 Uhr
Von: "Jonathan Wilkes" <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: Pd-List <[email protected]>
Betreff: Re: Aw: Re: Re: Re: [PD] Full stop '.' in class namespace
Von: "Jonathan Wilkes" <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: Pd-List <[email protected]>
Betreff: Re: Aw: Re: Re: Re: [PD] Full stop '.' in class namespace
> On Sunday, May 12, 2019, 12:27:33 AM PDT, Christof Ressi <[email protected]> wrote:
>> So why aren't all (or at least nearly all) external developers simply using "setup" as the entry point?
> yes, I've asked that myself and I think they just could. Have a look at the Max part of pd~: the setup function is simply called 'main'.
> yes, I've asked that myself and I think they just could. Have a look at the Max part of pd~: the setup function is simply called 'main'.
Here's the probable reason-- current practice is aimed at the maximally complicated library which has a makefile that allows it
to be built both as a single binary *or* with one class per binary. In that case you must have uniquely-named setup functions
per class that can be called from a central library setup.
Which I suppose would make more sense *if* the developer's choice of single- or multi-binary style was merely an
implementation detail. But even with your patches it isn't-- with multi-binary style I can do [declare -lib foo/bar] whereas with
the single-binary style that won't work.
-Jonathan
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
