Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Proposal:
What about moving these directories that can not be built as single externals out ot "externals" and give them their own subproject. This way, externals based on flext would be part of flext, and built together with flext. ?
I gave this a half day's worth of thought (and I think, we should move this topic over to pd-dev, which I'm doing now).
Here are some of my results.
*** flext itself needs a special treatment. ***
It doesn't fall into any of the current categories. It isn't an external, it isn't a library of its own, but it is needed to compile a bunch of other externals (by Thomas and me and maybe more.)
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.
*** 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.
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.
*** 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.
ciao