Enable gmt_dev.h to be used by external projects

Added by Paul about 3 years ago

The GMT API provides gmt.h (and what it includes) plus the API library. One can develop programs using those. However, those of us who are developing supplements (that may or may not be included as official) will most likely require access to gmt_dev.h. At the moment, such developers must build GMT 5 from source and do some manual copying of include files for their own code to compile outside the GMT/cmake environment. How can we improve this situation (this is mostly for ourselves)? Some ideas:

1. First rearrange existing include files and where they are included to reduce how many include files are needed to support gmt_dev.h. Many files are only used in building the library but nevertheless are included via gmt_dev.h. They should be included via gmt_internals.h or some new include file that all the gmt_*.c files include.
2. Unlike gmt.h, gmt_dev.h depends on config.h and gmt_config.h. The simplest way I can think of is to let the cmake process install more of the include files in the include dir, perhaps under a dev subdir. That way, GMT packages are built on their respective platforms and the include dir will have the right stuff. Hoever, last time I looked at this one problem was config.h being "too high" in the directory tree, i.e., above include so it was not so clear how to migrate it to, say, include/gmt/dev.

My aim is to enable someone interested in a non-offical supplement to download a tarball, run the configure or cmake step, and build a shared library that gmt5 can access via gmt.conf's GMT_CUSTOM_LIBS, without having to build GMT from source (i.e., they may have installed gmt5 from macports and got all the include files from there).

I am open to better ideas and approaches. I need this for my FZ supplement as well as when Sandwell and I will start ramping up the GMTSAR stuff later this summer.