On Sat, 15 Feb 2003, Frank Barknecht wrote:
It is very tempting to compile flext-ernals together with flext, because of compiler issues, but they should get a package of their own, or be included in the pd-externals package. The alternative would be to build-depend on a installed pd-flext-package. This looks cleaner, but might make things very complicated in the end (i.e. one would need to take care of version-depends and so on). But somehow putting flext-ernals in the same package as flext just *feels* wrong.
The problem with the build depends is that this is a Debian specific solution. In this case we have to come up with a proper configure script (and this is prop. true for every external depending on "unusual" libraries).
*** Other dependencies ***
Having externals only rely on themselves makes things easy for packagers and compilers. But 85 % of my externals depend on other libraries, and in this case it makes sense, IMO (of course). For example (flext-)iiwu makes iiwusynth available to Pd, which is very useful and it would be a wasted effort to try to reimplement libiiwusynth just for a 257 lines long external. But then flext can depend on STK and SndObj, to make a lot of things easier for external developers.
agreed.
Libraries might not be available and need to be packed as well (as you did with SndObj). Because of this, I would vote for a pd-externals package like now including externals without dependencies. But what to do with the rest? Each package might need different libraries, some need flext, some fftw, ...
I have no clear idea how to structure this, if we don't want to have packages with only one external inside.
You are right. The problem is not easily solveable. Sounds very much like the Gem dilemma.
*** Single externals are easy to install, libs are not ***
Libs require the user to add them to their pd-path. I'd prefer it, if a user will be made aware of this, maybe at installation or in the package README. So votes++ for a pd-extlibs package.
These thoughts are a bit chaotic, but might be valid for a deeper discussion.
Not at all, these discussions are important, and after all, using externals is one of the other "usability" issues that have to be solved.
I'll think it over again, and may come up with a more detailed list of the "higher level" externals.
Guenter