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.
...
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.
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.
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.
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?
Krzysztof