Hi, > 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. Yes - but also double size. I don't see how one could easily make a autoconf system that both works when stuff is separated and merged. > but i agree that distributing everything together is not a bad idea > per se -- after all ghostscript, gnuplot, all do the same thing. The main point is autoconf. Autoconf is a very very convenient tool to get stuff working on all platforms, but it can be annoying as hell, if you have to run it too often, because it is slow. And of course it takes quite some size. Having a big autoconf that gets accessed by all subpackages isn't a clean thing to do either, as actually the autoconf package would depend on all subpackages in the sense that any maybe-nonstandard feature a target uses must go into the autoconf system. > 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/... Yes. Look what I have done with the new snapshot generation scheme (look on FTP it is not yet integrated with the webpages). I suppose that you will like this better. And I do as well. We should explain how to use the packages and the order in which to build everything on the webpages as well ... > if that's done, everything becomes much better. I think that's basically done. IIRC the surplus "degas" toplevel dir is still in, but well. > 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. Yes - and too big. If you don't find the buildall script, you might be a bit lost ... > 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, Yes. We are sometimes a bit blind to the problems of newcomers ... we created this mess in the first place ... > 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. Yes. Though find -name "targets*" would get him there quickly :-). > 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). Independent from each other: Yes. Independent from the core: No. The latter is possible, but at a significant speed penalty - we'd have to abstract access to internal data. This is why we keep the targets with the core, thus effectively keeping targets together as well. > 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. What would you call "standalone target" ? It is very possible to compile a target outside the LibGGI source tree, but it means redoing all the autoconf stuff and including lots of internal headers. I got to recheck, if we install them all. Actually I don't like them being installed, as it might lure users into accessing internals, which they shouldn't. ... without the internal headers, they can't, > 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... I see. But that's IMHO not so much the point LibGGI is about. The primary message is: If you have the shared libraries and the include files, you can run and/or write LibGGI apps. The secondary message is: Using the metatargets you can do lots of nifty things with existing applications and targets. And maybe then, we have: If that doesn't suffice, you can still easily write your own targets. Just take a LibGGI source, pick a nice example, copy it and hack away. I think it isn't too important to be able to develop targets outside of the LibGGI tree. It's easier to work from the existing targets as starting points and the nice libtoolized and autoconfed framework of the core library. Enhances portability as well. > >> regarding distributions, if you build rpm packages I've done that now. Wasn't too hard after all. > 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... I'd be very glad, if you gave it a try. I have shunned building RPMs for quite a while as well, but after having tried it, I'd say it isn't too hard. Though it unfortunately is a bit hard in our special case, as we use $prefix to make internal replacements to config files ... CU, ANdy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
