[OpendTect_Developers] Dependencies

[Bert Bril]

Hi all,


Software engineers (Never went to school for it, but I consider myself
one) are usually obsessed with minimizing dependencies. True, without
dependencies you'd have to build everything from scratch - you can even
consider the OS a dependency. Things like User interface, 3D
visualization, network access, ... - no way you can build and maintain
that stuff yourself. For that, Qt and COIN are indispensable (but
covered by an interface layer in OpendTect).

Anyway: just adding loads of different packages because you want a funny
tool from each of them will get you in a nightmare of maintenance,
portability, release and you-name-it-what-else issues. Things would be a
lot easier if the world only had one good package management system (oh
joy), but Windows and Linux have never even come close to such a utopia.
Even in that case external interfaces tend to break or change or subtly
turn into bug nests - ugh.

I want to get rid of everything that is less than crucial. For example,
when Kris told me we could ditch FFTW for an internally managed SU-like
FFT without performance loss (he and Yuancheng actually managed to make
it faster), well, I was delighted. Now we have FFT without a big lump of
90% unnecessary functions, release issues, easy adaptation, ... the list
goes on and on.

The dependency avoidance has many faces. It also works within OpendTect.
The best way to make a system unmaintainable (well maybe not the best
but it's a sure way) is to dump all your code into one heap and let
everything call everything else. Moreover, a software engineer doesn't
only want to minimize, but also needs to know what is dependent on what.
For the big picture, we made modules - the different directories in the
OpendTect source (and include) tree. The dependencies between the
modules is mapped in the file ModDeps.od, in the Pmake subdirectory. On
Linux, this file is used directly by Pmake and it generates all sorts of
directives for make, compiler and linker. Let's take a look at the start
of the file:

Basic:                  S.Basic
Algo:                   S.Algo D.Basic
Database                S.Database D.Basic
General:                S.General D.Algo
Geometry:               S.Geometry D.General

We see that 'Basic' has no dependencies within OpendTect (it is
dependent on Qt core nowadays). Algo only depends on Basic. General
depends on Algo and therefore on Basic. And so forth. You will see there
are no cyclic dependencies, and that's final. Source files in Algo
cannot include source files from General. If such a thing would be
necessary, the options include:
* Move the file to General
* Use a virtual interface with a factory
* Use CallBack's
... that sort of thing.

A consequence is that people who want to integrate OpendTect stuff into
their programs (i.e. not plugin programming but stand-alone) don't
necessarily have to link with everything we've got. Just find the lib
highest up and link all dependent libs, too. That will work for 'batch'
stuff (for the Windows people: stuff without user interface), but also
if you just want a bit of the UI. For example, you can do quite a bit
just with uiIo, which is defined as:

uiIo:                   S.uiIo D.uiFlatView D.Geometry

This explodes to uiIo uiFlatView uiTools uiBase Usage Network Geometry
General Algo and Basic (and a lot of Qt libs). You'll not see 'vis'
stuff there, meaning there is no dependency on COIN hence OpenGL. You
won't have COIN dependency all the way up to uiWellAttrib.


Oh it's getting too long. I'll stop for now ...

/Bert

-- 
-- 
-- Bert Bril / OpendTect developer at dGB
-- mailto:Bert.Bril at opendtect.org , http://opendtect.org