Re: [Adonthell-devel] 0.4 cleanup [IMPORTANT]

[Kai Sterker]

Alex wrote:

> Once I have your agreement I'll probably write some extra programming
> rules down:
> 
> - src/Makefile.am now contains a variable indicating the
> subdirectories of the different modules (to avoid duplication when
> building tools or not).
> 
> - The SWIG_MINVER variable set in configure.in allows to control which
> minimal version of SWIG is required over a single variable. It is also
> used to display the correct error messages in the Makefile.ams.
> Whenever we need a newer SWIG, just increase it, and voila.
> 
> - The Makefile.ams have slightly been changed so compilation is
> possible in another directory than the source directory. 

Cool.


> As a rule, every .cc file should start with "using namespace
> my_namespace;" where my_namespace is the namespace it belongs. That
> way the code won't be bloated with namespace resolution operators, and
> I don't think it can lead to confusion. Every .cc file in gfx/ should
> then start with "using namespace gfx;" for instance.
> 
> The best IMO would be if we limit, as far as possible, the "using"
> directive to the namespace the file implements. That is, no "using
> std" and suchs. As far as possible, once again - but in the code I've
> changed so far, it was just fine.

Makes sense. Shouldn't be a problem to do a search/replace on the
existing code. And when compiling with gcc-3.x you'll be forced to add
the <namespace>:: where necessary.

> What would be STRICTLY forbidden however, is to use "using" in .h
> files. This is very, very bad design and we did it only because our
> SWIG version required it. I hope the latest will be able to handle
> this without problems.

I should think so. After all it's said to fully support namespaces now.

 
> Things I'm a little bit worried about (but that's not very serious -
> at least the code already so much clearer):
> 
> - For every library I'm obliged to include the python cflags
> everywhere, just because the wrapper file requires them. Other files
> doesn't need them, but I can't write a build target only for the
> wrapper files. This make me think that maybe we should separate the
> Python wrappers from the libraries.

Hm, why not. We could make a 'wrapper' lib or something.

> - If you type, say, "make alextest" in src/ while the needed libraries
> aren't build, all you will get is an error at link time, because the
> src/ 's Makefile.am doesn't know how to build the sub-libraries. Not
> very serious, but maybe there is an elegant way to workaround this?

Again, this is not tested, but from the exult src/Makefile.am

EXULTLIBS = \
        pathfinder/libpathfinder.la             \
        audio/libaudio.la       \
        audio/midi_drivers/libmididrv.la        \
        [...]

exult_DEPENDENCIES = $(ICON_FILE) $(EXULTLIBS)

I imagine that does the trick.


> - The Makefile rules for creating the wrapper files are now duplicated
> in each subdirectory. This is bad design, as they are always the same.
> Does anyone know a way to have them declared at only one point?

If you'd separate the .i file into a directory of their own and build
all the wrappers at the end it would be possible. Of course, thats only
possible if you no longer link them to the various libs. But as you are
playing with that thought ...


> Eventually, the src/ directory should *only* contain the modules
> subdirectories and the main program file.

Agreed.
 
> Yet, it still contains the base/rpg (that we need to separate) stuff,
> and atk.

We'd need a rpg module at least. 

 
> I think it would be safer to put all our Python modules in a
> "adonthell" module, to isolate our own modules from system/3rd party
> modules that might have the same name (as map, gfx are quite standard
> names). And doing a "from adonthell import *" wouldn't hurt anybody
> anyway.

Would be already enough to store them in a directory called "adonthell".
Or do you mean that?


> Another thing I thought about (but that should rather be in the
> post-0.4 plans), is that maybe we could distribute our modules as
> shared libraries. This would allow two things:
> - More 3rd party control over our word, as someone could well link
> dynamically to our libs,
> 
> - Distributing the tools (like dlgedit) in packages separated from the
> main source tree, which would be much much cleaner.
> 
> In this case, separating the Python wrappers from our libraries would
> make sense. Well, don't worry too much about it for now, it's just a
> random idea - let's think about us before thinking about letting
> others easily use our code! ;)

Right. But if it helps to further clean up the code that'll be the way
to go. However, as you say, that can wait until later.

Kai