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
