adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] First step for modules creation


From: Alexandre Courbot
Subject: [Adonthell-devel] First step for modules creation
Date: 16 Mar 2002 18:26:52 +0100

I've cut our huge libadonthell.a in smaller libs that should reflect the
directory/namespace structure we will adopt in the near future. Of
course, this is only a first draft - actually I'm waiting for you guys
to have a look at Makefile.am and improve a bit the structure. I fear I
might have made too many libs. Here they are:

-base contains the file access functions, the game time management and
the basic callback mechanism. Maybe we should put a global
initialisation function there to initialize SDL without any subsystem.

-input contains the input manager.

-gfx contains the base gfx classes: screen, image, animation, etc.

-audio *will* contain our base audio classes ;)

-python contains the Python management classes. That is, our bindings to
the Python functions - it is in NO CASE related to our Python wrappers
which would be included no matter if you link to this module of no.

-map contains the new map engine

-gui contains the GUI

-oldwin is the old window system

-adonthell is... what remained ;) this includes the old input system,
that I'll probably wipe out anyway.

Some modules are of course dependant of each others, and the order is
made to reflect this. map depends on gfx which depend on base, etc...
Maybe there is a way to reflect these dependancies in the Makefile,
without having libmap for instance directly including what it depends
on?

Don't know where to put the dialog system. Is it worth to create a
subdirectory and namespace for it? Should it be a part of a larger
module, related to role playing? More generally, what is our policy for
these modules? What should make something go into a module and not
another?

The main result of this change is that Makefile.am is *a lot* clearer.
Having small libs is much easier to handle than one large one. Also,
When you build alextest, the useless stuff (like the GUI, the Python
module, ...) isn't build anymore.

All in all, divide to reign is a good strategy! :)

Alex.
-- 
http://www.gnurou.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]