In reply to Andreas Beck <[EMAIL PROTECTED]> > >I didn't say it can't be done, but it just doesn't make sense. A >quick check says that a whole LibGGI tree is around 600k compressed. > >Now when I pick out the autoconf stuff, which won't split well, but >needs to be duplicated for all targets, if you separate it, it >amounts to 125k compressed ... > >Considering that we have 49 sublibs (targets and renderers), that >would give an overhead of 6 Megabytes for a full separation. And even >a more reasonable approach that keeps some stuff grouped (like all >memory renderers, all X targets etc.) will quickly be the double size >of a full LibGGI package. > >Not to say, that some people - like me - will be annoyed as hell, if >they have to download about 50 files for a full set. even if the size doubles, as with your last suggestion, i don't see a big problem. you will have a bunch of separate files, but -- nothing says you can't have a ggi_all.tar.gz file, which has everything. but i agree that distributing everything together is not a bad idea per se -- after all ghostscript, gnuplot, all do the same thing. the separation of targets is more of a thought inducing experiment, see below. i guess my biggest problem now is that the directory structure of the `degas' distribution is not clear at all. to reach a target/renderer you have to go through degas -> lib -> libggi -> display. the distribuition should, imho, untar to something like libggi-1.2.3/targets/... libgii-5.6.7/... if that's done, everything becomes much better. to the outside hacker public looking into /degas it seems that things are too dependent on each other, and the huge directory tree is somewhat confusing. right now i'm starting to think it is not, but i remember the first time i saw it i was very confused --- and that's all that matters, since after a long time anybody gets used to any code. ask anybody who knows only what ggi is and what a target is (but never saw /degas) to untar degas and find the targets. it is not obvious. my target separation suggestion was something to induce thought: if you can't do it in a clean way, then the distribution/system has to be rethinked because targets are supposed to be pretty much independent entities (or at least most of them should). the message is this: if you tell me targets cannot be cleany separated from the lib source, what you are in effect telling me is that it is difficult to write a standalone target. the message that should be passed is: if you have the shared libraries and the include files, then you can write any new target you want. that is, imho, not the message passed by loooking into /degas... >> regarding distributions, if you build rpm packages please consider >> building debian packages too. in this way you reach out almost >> everybody, including those who choose to use good distributions ;). > >Of course. Though I think it would be best, if someone with a .deb >based system would make them. He can test them ... yeah, i'm in a .deb based system and i have no idea on how to do them. maybe when i start producing .debs for my own programs... -- Cesar Augusto Rorato Crusius __o __o __o __o __o Stanford University _`\<, _`\<, _`\<, _`\<, _`\<, e-mail:[EMAIL PROTECTED] (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_) www.stanford.edu/~crusius o _ _ _ __o __o __o __o /\_ _ \\o (_)\__/o (_) _`\<, _`\<, _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/ (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_ He who sacrifices functionality for ease of use Loses both and deserves neither