On Mon, 9 Jun 2003, Thomas Grill wrote:
- they are not as flexible for distribution
why? I think they are easier on the contrary
Ok, I have a patch that uses xx from xxlib, yx from xylib and zz from zzlib. In order to distribute this patch to my friends and not let them go through recompilation nightmares I have to include the whole libraries for win/lin/osx, whereas with single externals I just have to include the respective pd_linux files. (Additionally I do not even need to bother about externals and library conflicts that might occur on the others system, because the externals I have put there will be automtically loaded.)
Ok you say we could improve the configuration system, but why ?
- it is hard (if not impossible) to implement a system that allows for
reloading.
Why is it harder to reload a library than a single external? (to my mind for this there has to be some cooperation by the external anyhow)
Because for a library you have to search for all externals that are implemented and reload them, and you do not even know who they are.
- they do not fit in the system for externals that we designed for the CVS. (which is based on single externals, actually I do not see any other way the idea could be implemented)
Does flext and the derived externals fit into that system at all?
What are the arguments against single externals ?
I have no argument against single externals as i use them myself, but i'm pro using libraries if feasible. It's possibly only important for me so that may not be enough of an argument, but for all externals depending on a base class (via c++ inheritance) which is an important flext feature the usage of separate external binaries is hardly possible as it necessitates the usage of a shared library file with the base classes, which is even more difficult to handle.
So C++ libraries are hardly possible and if so very difficult to handle ?
For all externals depending on shared code or data: why would the usage of an extra shared library be easier than the usage of a single external library file?
Well, there would be some advantages to that approach at least. For example you can fix things in the library without requesting all flext external developers to recompile.
Anyhow, sometimes the shared code size is that small that it doesn't pay off to make a dll. I have the dream that the pd devlopers would in this case work on a common library of support functions that are probably missing fro pd, and which , based on this work can probably be moved into pd itself.
As a last word on this topic, I think single externals make it easier for the pd developers to work together. This is one of the main goals for the CVS too.
Greetings,
Guenter
best greetings, Thomas