[PD-dev] External Manager - Load my Externals

[guenter geiger]

On Wed, 4 Jun 2003, Krzysztof Czaja wrote:
> hi Guenter, thanks for answering my stupid questions!
>
> guenter geiger wrote:
> ...
>  > Yes, but considering that there are only useful externals there,
>  > it makes sense to install them all (hard disk space is cheap, and
>  > pd with externals is still small in comparison to other software)
>
> well... there are likely a few thousand Pd externals that are more
> or less useful, in a couple of years.  That could be too much for
> my brain space.  I also fear the older patches will gradually stop
> working, if their abstraction names are stolen by new externals
> that will be introduced.

with single externals it will be easy to prevent that scenario.
E.g., you put the externals you need in your specific pd project folder,
this way abstractions and externals are treated the same way,
you can even distribute the projects platform independent, without
having to tell people to install/compile the externals themselves.

> ...
>  >> >>Another advantage of single over libraries of externals is that name
>  >> >>conflicts are easier to spot.
>  >>
>  >>but are not they harder to resolve that way?
>  >
>  >
>  > no, they are not harder to resolve. They finally get resolved.
>
> I meant getting people to agree on what is good for all of them is
> usually harder than letting every self choose what it wants.
>
> Of course, if there is a standard set of externals, there should
> be a corresponding standard set of names.  So, for example, I have
> been annoying everybody, many times, with the ``standard max/msp
> names should be reserved'' theme.

Which is definitely an important topic, can't remember all the issues,
but some of them where pd internal (which should be resolved inside pd).

>
> But the non-standard externals, i.e. most of them, would have been
> easier to maintain, if there was a name resolution scheme based on
> the combination of per-user configuration and dependencies stored
> in .pd files.

That is the point I am trying to make with single externals. It is
already there, nothing to implement, we only need to tell people.
The name resolution can be arbitrarily configured by the person who
writes the patch. This way abstractions and externals are naturally
treated the same way.

You can even make collections of externals by putting them in a subfolder
and instantiating with <subfolder>/externalname.

I can not think of a name resolution system that is more flexible.

>
>  > No, the #include thing is they way how "links" are implemented in CVS.
>
> I have not given it much thinking yet, but I would start with what
> seems like a more natural way of building a collection of
> externals:  run make on every directory in the list, then consult
> another list to pick the needed binaries from wherever they went
> to.  Just two files to maintain for every platform: linux.dirs and
> linux.binaries, etc.

One goal of the setup was to have only (simple) one makefile per platform.
I wanted the build process to be controllable and if something changes
fixable. You are right that it might not be the most natural way,
but it works out well until now.

With the scheme we have now it is easy to add a new platform, compiler,
whatever.

>
>  > Another topic is shared code. I think shared code could go into a dll.
>  > A standard dll gets automatically loaded when the first external that uses
>  > it gets loaded.
>
> do you mean loading by a stub, or by some yet-to-implement magic
> in the Pd loader?

It gets loaded because it is a dll.

If you link your external against libogg, libogg gets loaded.
If you link it against "myext.dll" myext.dll gets loaded.

Of course if you have to execute some code during loading it gets
slightly more complicated. But no additions to pd needed.

Greetings
Guenter