GMT5 Release Endgame

Added by Paul almost 5 years ago

Hi guys-

We have ~4 weeks to wrap up GMT5 for release. For this to happen we need to get organized. I started this thread to keep track of where we are. Below are the tasks I think we have to complete as well as some unanswered questions. There may be more tasks.

  1. Separate libgmt.* from libgmtsuppl.*. My understanding is that we need some cmake changes to create libgmtsuppl.* separately from libgmt.* and add the suppl modules to that lib instead of libgmt.*. The libgmtsupp.* would depend on libgmt.*. Regardless of our plug-in plans it would seem we should be able to do this step separately and just adjust cmake files to link gmt.exe with both of those libs for the moment (before doing the plugin steps below).
  2. Create a separate subversion project for libgmtext.* shared lib. I think the word "extension" is better than "custom" so I suggest we use libgmtex.* and gmt5-ext as package name. It would start out with a few examples like (gmt)average, (gmt)mercmap, and perhaps 1-2 demo modules to illustrate the use of FFTs, grids, etc. This would be a developers package gmt-custom that gurus could install and add their own modules. We would oversee and include future custom modules as the project grows. So we need a bare-bones cmake project that just builds libgmtext.* and no executables.
  3. Finalize the rst docs in order to build the PDF, HTML, and MAN items, including solving figures.
  4. Probably name the single executable gmt5 instead of gmt. I think Florian said we should leave that decision to package managers but it is not that simple. All the GMT examples and test scripts now call GMT modules via the gmt executable so we need to know if it is called gmt or gmt5. It would seem to me that we should just call it gmt5 and that way it would not clash with gmt4 provided one uses the gmt5 syntax (gmt5 module) when using gmt5. Likewise, a distant gmt6 would coexist with gmt5. Links would be a separate issue which obviously cannot coexist unless in different paths.
  5. Implement plugin loading. Florian has a demonstration of this in branches/plugin. The gmt5 exe would dynamically load the modules that are requested, looking in the core lib, the suppl lib (if found), and custom libs (via GMT_EXTENSIONS parameter and if found). This seems to work for me; perhaps merge in changes once items 1-2 are done?
  6. Update the alloc_mode definition and usage and fix the img2grd bug.
  7. Let become, with link to GMT4 page (rename to or something); keep gmtrac link for backwardness.

Like all of you I am swamped (proposals, in particular; also relocating to Hawaii in early July) but we have to push on. Unfortunately, my cmake skills are not good enough to handle tasks 1-2 unsupervised which will require Florian/Remko to do the heavy lifting. I will need to take on item 6, and can do 5 if we need to change all scripts/refs to gmt5. JL, it would be good if you could try to build branch/plugin on Win so we know if there are any unforeseen issues with DLL loading.