Hello, > Miguel wrote: "I would be interested in understanding what the issues of > non-splitting are, from the GNOME point of view." > > For one, if in the future Gnome would like to provide an embedded version > (there was some talk about it already), it would be easier to pick and > choose components as seen fit. In a 64 MB firmware you can't fit > everything, usually... Of course, I don't think that this means that you > need 3 different tarballs instead of 1. As long the selective functionality > is present in your current tarball (via an autoconf option), I don't see why > it should be physically split in different tarballs. But some form of > seperation must exist as the rest of the Gnome is very modular in its > nature.
Nothing is stopping embedded developers from just shipping the libraries from Gtk# that they need, they do not need to ship everything that the tarball contains. In addition, you might not even need a full binding of Gtk# or any of the component libraries, or even the Mono components in an embedded deployment, you might just need a subset. This is in fact, one of the problems with the Compact Framework from Microsoft. Someone decided "This is what we will support on an embedded system" with no consideration for the fact that embedded systems are hardly the same, and the kinds of applications are always different (the guys screwed by Microsoft are some of our major users: they copy-paste Mono's class library code so they can get features that Microsoft left out). The right approach is to use a tool that can take a library, and using a specification that contains the features required it produces a "light" version of this library. There are commercial tools that do this for CIL libraries, we have our own `monodiet' which is being replaced with a simpler and more complete `CIL Linker' based on the Cecil libraries. Miguel _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
