Re: [AD] Allegro generalization/extension mechanism

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


The separation will accomplish one major thing: it would be easier to
edit one part of the library without worrying as to how the other
parts will be affected. Ideally, There won't be any global variable
usage hacks at all ...

Second, as Elias pointed out, the internal structure of Allegro is
small, and the power user can vary his binary distribution according
to his needs. And yet, it wouldn't make any difference to him from the
normal-end-user perspective.

Third, it's more of a developers concern than an end-user-thing. It's
easier to have things edited side by side .. it leads to better, more
robust release cycles..

On Mon, 14 Mar 2005 22:11:44 -0800, Chris <chris.kcat@xxxxxxxxxx> wrote:
> guilt wrote:
> > I'm not saying that the whole thing must be distributed separately..
> > release it like "allegro-project-4.3.x" which contains "allegro-base"
> > and "allegro-impl" and "allegro-stdext" ... if you like.. but within
> > that, make sure that "everything is present". All I'm saying is that,
> > make it "modular". It's easier to maintain Alegro that way...
> 
> If they're all gonna be distributed in the same package, and all be
> maintained by the same developers, why seperate them? What will it
> accomplish? Allegro can be (and already is, somewhat) modular without
> having to be split up into seperate libs.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 


-- 
Karthik
http://guilt.bafsoft.net




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/