You missed the points. I don't want "standard" distro integration to be a massive work. Now it's near unreasonable to integrate a proper desktop distro alone, and it's quite worse from a "SDK" point of view. It's good for the business of distro integration: coze a small team, or a sole coder cannot "compet" reasonnably. I'm being ironic, but I don't think I'm far from the truth.
High level script languages are *many*. And forcibly used in many base components. Perl5 in autotools, apt/dpkg (have to re-check), ruby for grub2, python for portage, javascript for desktops (gnome) and I don't count all the "code generators" SDKs do have. Last time I tried to get rid of the autotools from the glib (not glibc), I ran into perl5 and python2 (and not 3!!) code generators. For libsnd, I discovered a crazy code generator written in GNU guile. Of course, each high level scripting language has to manage its module dependencies and so on, and it's of course of massive kludge... yes nearly *each* of them. People choosing to code using C with some libs, did choose it perfectly knowing that they will sacrifice some comfort compared to *insert your favorite high level scripting language* with *insert the chosen framework specific to that high level scripting language*... (the funniest is PHP with its tons of different www frameworks which do not work together but aim at the same thing). That works with crazy complex statically compiled languages like c++/java (which is probably the worst)/etc. Then, yes, I dont want all those things as system dependencies, coze I don't want to have to maintain integration on those very expensive pieces of software. The hard part, they will have to do it: to bundle in their SDK those thingies. It would solve only one part of the pb, coze I'm sure they would use build systems like cmake or the GNU autotools, then making the removal of those for some basic sh scripts or basic makefiles, a real nightmare (and I already put forward the issue of code generators). -- Sylvain
