[OpendTect_Developers] Module dependencies in batch programs

[Bert Bril]

Hi all,


We have now tackled a problem that we had only rather ad-hoc solutions 
for before. We put the solution in all repositories, so you'll get it in 
every new patch release.

The issue is that if you make a batch program, then sometimes you need 
initialization and load of libraries that are not used directly by your 
program, but are necessary to load a plugin to the program. Thus, you 
make a batch program that loads one of your own plugins which in turn 
uses more libs than the linker sees when making the program. I'm not 
sure whether this is a real problem on Windows or Mac, but it certainly 
is on Linux.

For that, we made a new object that reads the 'ModDeps.od' file and 
makes the dependency structure available inside OpendTect. Note that it 
is read from the data subdir (in which we'll put it in future 
installations) or if it's not there it will try the Pmake subdirectory 
(where it is now and will still be in the future for development).

Then, every module in the OpendTect tree now may have an extern "C" 
od_##modulename##_initStdClasses() function. od_main now calls all these 
at startup. Your batch program can do the same, by simply stating the 
highest dependency. For example, HorizonAttrib/od_isopach.cc now has:

#include "moddepmgr.h"
// ...
OD::ModDeps().ensureLoaded( "EarthModel" );

That's it, the HorizonAttrib plugin doesn't use 'higher-up' stuff.

Note that you now more or less *have* to do this in every batch program 
that uses things that are initialized (like factories) in the 
initStdClasses functions. In doubt, just do it. If you don;t know what 
to do, try OD::ModDeps().ensureLoaded( "WellAttrib" ).



शांति / امن, Bert

-- 
-- dGB Earth Sciences B.V.
-- Nijverheidstraat 11-2, 7511 JM Enschede, The Netherlands
-- mailto:Bert.Bril at dgbes.com , http://www.dgbes.com
-- Tel: +31 534315155 , Fax: +31 534315104