Getting started with OpendTect development

In principle, anyone can build the full OpendTect system from source. Fortunately, OpendTect has a plugin architecture which makes it much easier to start developing. Therefore, this manual will focus on plugin development rather than building the entire OpendTect from scratch. If for some reason you are interested in building the entire OpendTect, follow the instructions for plugin development before going here. Even if you want to build for a completely new platform, the first step would still be to get your environment ready for plugin development.

For both types of development you should have installed a fully functional OpendTect system before you start. Even when you build the entire OpendTect, you'll want to be able to use some of the libraries from the distribution.

MS Windows-based developers should not be here: instead, go to the windows development section.

Before you can start developing, there are a few external programs that need to be installed.

The following programs should be available:

• CMake
• GNU gcc/g++ >= 4.1.x
• csh (just make sure you have one installed).

CMake is used to build both the entire system as well as plugins.

Setup ODWork dir

First of all, we strongly recommend to have no spaces in the path to your ODWork directory. A good place for your ODWork directory may be your home directory.

As you will need to consult the OpendTect header files all the time, it may be handy to set links to the include directory in the installation, as in:

ln -s /apps/OpendTect/5.0.0/include .

Testing the installation

After "cmake ." (ceemake dot) in the root of your development environment you can simply use make in each plugin directory. As a test try to make plugins/Tut. The result is libTut.so in bin/platfor_dir of your WORK. You can load this into OpendTect (menu Utilities-Plugins). You'll see it goes by default to the bin/platform_dir of the installation. The libTut.so there is the one we pre-cooked. You'll need to go to bin/platfom_dir of your own WORK, and load that plugin. After that, you can make and load uiTut (libuiTut.so). You should now see these plugins in the list of the plugin manager, and there should be a new submenu in Utilities-Tools.

Your own plugin

To create your very own plugin, we added a directory 'My_Plugin_Name'. Change that directory name to how you want to name your plugin. No spaces please. Example: 'PsychicFreqEst'. You want to get this name in all details now. So:

mv My_Plugin_Name PsychicFreqEst
cd PsychicFreqEst
mv my_plugin_name_pi.cc psychicfreqest_pi.cc

Now edit both the CMakeLists.txt and psychicfreqest_pi.cc, as in:

vi CMakeLists.txt psychicfreqest_pi.cc

CMakelists will need the changed file name, 'psychicfreqest_pi' instead of 'my_plugin_name_pi'. Then go through the psychicfreqest_pi.cc file and change everything appropriate, at least 'My_Plugin_Name' to 'PsychicFreqEst'. Then .. first go back to $WORK to change CMakeLists.txt there, change 'My_Plugin_Name' to 'PsychicFreqEst'. Because you have changed a directory name ... Then run cmake . ... or just 'make' (nice tool, cmake). You can imagine having to add other plugins, there, later.

After that 'global' cmake reconfiguration, you can go to your plugin directory (i.c. plugins/PsychicFreqEst) and do 'make'. Again you can load the plugin (libPsychicFreqEst.so), and a message 'Hello world' should be the result.

To change the implementation, you would want to change some more stuff, like the message. Look in my_first_separate_source.cc and change "Hello world!" to "I sense your frequencies!". And so forth. For useful changes, take a peek at the Tut plugins and the documentation.

Unloading plugins (NOT)

There is no way to un-load a plugin. That means you have to exit OpendTect to test a new version (e.g. after recompile). It's nice to have auto-load in place, therefore (read on). Also interesting may be the usage of the Command Driver.

Installing your plugins

Installing a plugin means: making it auto-loaded. This removes the nuisance of having to load the plugin each time you start OpendTect. On the other hand, when you're still developing you may not want the plugin to be loaded all the time. Anyway, the plugins are installed by linking or copying them to the correct plugin subdirectory in either your personal '.od' settings directory, or in the program installation directory and making a configuration ".alo" file.
This is the same on Unix and Windows, so please consult the plugins auto-load and installation documentation for more details.

Distributing your plugins

The distribution of plugins is basically the same for Unix and windows, see the plugins page.
Just copy the .alo files into the plugins/platform directory ($DTECT_APPL/plugins/$HDIR) and copy the actual plugins into the bin/$DIR subdirectory, where all shared libs reside.

For distribution to the outside world, you'll need to package your plugins, documentation, etc. into zip files. If you're in the mood for really going public, you'd want to be in the installation manager. Then read the plugins page and then contact support at opendtect.org.

Building from source

If you're really into it, you can build the entire OpendTect from source after you've installed OpendTect and built a plugin. For that, you will have to get hold of a Qt and a OpenSceneGraph source distribution. This is because you'll need the correct header files to go with the libraries.

Qt

Qt is used for the GUI. Use the Qt 5.9 (or newer Qt5) release. We configured with:

./configure -shared -release -no-gif -enable-opengl -thread -no-g++-exceptions -disable-xml -disable-sql
 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -qt-libpng -qt-libjpeg -qt-libmng -qt-imgfmt-jpeg -qt-imgfmt-mng -qt-imgfmt-png

OpenSceneGraph

You need to install a version of the OpenSceneGraph system.

OpendTect

Now, you can configure cmake. As always, do a 'cmake .', this time in $WORK itself. If configuring succeeds, 'make' should do the trick.