[Adonthell-devel] 0.4 source structure proposals and questions

[Alexandre Courbot]

Fine, I'm starting to come with something nice about that!

First, here's how I think things should be done and how I've done so
far:

First keyword: modular! Exit the big monolithic binary we had in 0.3.
0.4 will be made of several libraries that other programs will be able
to link to, in order to make 3rd party projects using our work. As a
consequence, include files should be installed as well, using the same
hierarchy that they do in the source.

Second thing: Python integration. While 0.3 needed the use of a special
binary to exploit the Python extentions, 0.4 modules will get installed
in a way so we can launch any Python interpreter, type, say "import
adonthell.gfx" and start having fun.

Concretely, what is done?

As before, the source structure is made of one directory per module:
|
|-base
|-gfx
|-audio
|-...

Every directory corresponds to one C++ namespace and one Python module,
as said many times before. The building rules are very clean (the
Makefile.am for gfx makes 44 lines!) and do the following (in the case
of gfx):
-The headers will get installed to $(prefix)/include/adonthell/gfx
-A libadonthell_gfx library gets created and installed to $(prefix)/lib
(maybe we could put our own libraries to $(prefix)/lib/adonthell later,
for a better organization - libtool seems to be able to handle that).
This library does *not* contain Python wrappers.
-Another library, libpygfx.so, is made from *only* the Python wrappers
and is dynamically linked to libadonthell_gfx.
-The gfx.py Python module is installed to
$(prefix)/lib/python<version>/site-packages/adonthell, along with
libpygfx.so. A symbolic link is then created from libpygfx.so to _gfx.so
so the module can be imported.

And voila! Then, opening a Python interpreter and typing "import gfx"
will work, since the wrapper is linked to the actual library and the
actual library is linked to all its dependancies. This will be great for
quick application developments (say, editors).

Of course, I'll also have to make gfx backends before that. But I wanted
to show you what was going on. All the above has been tested on my
system.

There is one issue that prevents me from releasing the package today.
While automake and libtool handles perfectly dependancies against
installed libraries and libraries that get build by the same
Makefile.am, I get problems for dependancies like "libgfx relies on
libbase, which is in ../base". Of course, I could play with -L and such,
but that's not very clean. I think I'll ask that on the automake list
tomorrow.

Another (minor) issue is that there is no proper autoconf/automake
Python macro to build extension modules (although there's everything
needed to know where to install them). That is, something that gives
PY_LIBS and PY_CFLAGS as well as does the "little" macro Kai wrote.
Nothing dramatic though, we can still use Kai's one, and maybe even
rework it a little bit and submit it for inclusion in autoconf. After
all, that's what free software is about and your macro works flawlessly
(not to mention it has been tested quite a lot by all the people who
compiled Adonthell). From what I've seem on the ML archives, many people
are waiting for a proper Python detection in autoconf.

Well, that's about it. More tomorrow or in the next few days. Please
share your thoughts! :)
Alex.
-- 
http://www.gnurou.org