Hi, 2014-04-27 9:47 GMT+02:00 Jonathan Aquilina <[email protected]>: > here is the reason that gentoo doesnt like bundled software > > https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
These are good reasons but we are having good (better) reasons as well. First of all, we're not bundling ZynAddSubFX but integrating it. That's a huge difference both from a technical view and from the user's perspective. ZynAddSubFX is not a shared library making it impossible to link against it. However we need to link against it in order to integrate it (i.e. call the functions for fetching the sound data, sending MIDI events/controllers, pitch wheel bend range update etc.). That's only possible by compiling in the sources. Furthermore we need to modify the sources for proper integration, e.g. disabling the confirmation-dialog at exit. Otherwise you would always have to confirm to close the ZASF GUI whenever you hide it (when removing track, unloading project, clicking the "Show/hide GUI"). Furthermore we use our own Qt-based XML backend so the original mxml library is not required. In order to be able to use an external ZASF, they would have to move everything into a shared library and make the ZynAddSubFX binary just a minimal binary with a main() function which calls the according functions from the library. At the same time the headers would have to be provided as an SDK (-> libzynaddsubfx and libzynaddsubfx-dev). I can't say anything about resid but I'd guess it could be a difficult dependency as not all distributions have it. Regarding the LADSPA plugins: there's the possibility to exclude them from build however this leads to the major problems that the LMMS userbase does not use the same plugins and/or the same versions. One good example: CAPS. There's the 0.4.x series and the new 0.9.x series. Both of them are not compatible, many plugins inside got renamed, removed or added. In LMMS we have the 0.4.x series which has been working well for years. If a distribution decides to remove our caps.so and depend on their own CAPS 0.9 package instead (which is present in e.g. Debian Stable, Ubuntu 14.04 etc.), the user definitly won't be able to properly open and play back older or external projects as he will be missing lots of plugins even though he has CAPS. This functional break could even result from a simple package or system update where LMMS itself isn't touched! That's why I'm still in favor of bundling integral parts of LMMS so they're strictly under our control and the users get the best possible experience and compatibility. (for the CAPS problem we can build a smart upgrade path somewhen later and even provide the old CAPS library for compatibility) Toby ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
