GSHHS built-in or separate?

Added by Remko over 5 years ago

I was wondering if we should consider to completely "divorce" GSHHS from GMT.
Already in the Fink packaging we have gone the route of a separate package.
And the CMake configuration already can look for the data base elsewhere, but then copied it into GMT.

Copying is, of course, essential when you have just temporarily unpacked a GSHHS tarball somewhere, and it needs to get it's permanent place.

But consider that you already have GSHHS installed (for example through the Fink package). Then it could stay where it is.
All GMT then needs to do is to install a link to GMT_SHAREDIR/coast, or, better, compile this location into the software.

Currently, I believe, GSHHS always needs to be in GMT_SHAREDIR/coast. Should we except something different? Or should that only be possible with an environment variable? Or allow both to locate GSHHS?


Replies (6)

RE: GSHHS built-in or separate? - Added by Paul over 5 years ago

Link might be more awkward for Windows?
Another option might be to introduce a gmt.conf parameter
DIR_GSHHS =
which if empty means use the standard install/share/coast

A related issue is the src/coast directory with a hodge podge of stuff relevant for me to maintain GSHHS. I should probably move that out to a separate repository. I have already done that with the GSHHS original data files from which the GSHHS distribution derives so I will add an action for that.

Paul

RE: GSHHS built-in or separate? - Added by Remko over 5 years ago

Ah yes, that's a good idea, to introduce DIR_GSHHS in gmt.conf, with GMT_SHAREDIR/coast as default.

Only we need something to be added in the configuration that says if the GSHHS data set needs to be moved into the GMT installation directory or whether it can stay put.

Maybe it's time I start to learn to do the CMake configuration to get that done.

RE: GSHHS built-in or separate? - Added by Joaquim over 5 years ago

Paul Wessel wrote:

Link might be more awkward for Windows?

Links exist "officially" on Windows since Vista but that would leave out the XP users which still almost half of the Win users universe.

Another option might be to introduce a gmt.conf parameter
DIR_GSHHS =
which if empty means use the standard install/share/coast

A related issue is the src/coast directory with a hodge podge of stuff relevant for me to maintain GSHHS. I should probably move that out to a separate repository. I have already done that with the GSHHS original data files from which the GSHHS distribution derives so I will add an action for that.

Paul

RE: GSHHS built-in or separate? - Added by Florian over 5 years ago

I would very much appreciate removing GSHHS. While it is quite straightforward to implement for fixed-path installations by package managers (fink, macports, apt, yum, rpm, ...) this complicates things for relocatable copies (OSX app bundle, Windows installer, binary TGZ+ZIP packages). Since r9833 GMT is now fully relocatable on Windows and *NIX. That means it can find its share directory and libraries without the need to set GMT_SHAREDIR or LD_LIBRARY_PATH. I hope this encourages people to not set these environment variables and hence reduce the amount of questions like "why does GMT not find its cpt files?" or "why is there a version mismatch when I have GMT4 installed in parallel?". Still waiting for feedback on #18...

Now back to the topic. I suggest following the spirit of #18 and make GMT search for GSHHS based on these criteria (in order):
  1. search in the path GSHHS_DIR set in gmt.conf (local user override; note that you cannot set GSHHS_DIR in the global gmt.conf in GMT_SHAREDIR)
  2. search in the path from the environment variable GSHHS_DIR (global user override)
  3. search in GMT_SHAREDIR/coast or GMT_SHAREDIR/GSHHS-<some version> (in case GSHHS was bundled with GMT and was not installed separately)
  4. search in hardcoded location GSHHS_DIR from FindGSHHS.cmake (this is good for fixed-path installations)
  5. and if all other failed, search GSHHS during runtime in based on GMT_CTRL→init.runpath (this is the case when the installation dir was relocated, e.g, OSX bundle, Windows installer)
Common search locations for the latter should include:
  • Windows: runpath/../../GSHHS-<some version> (e.g., c:/programs/gmt5/bin and c:/programs/gshhs-2.2.0)
  • OSX: runpath/../../../../GSHHS-<some version> (e.g., <Bundle root>/GMT-5.0.1b.app and <Bundle root>/gshhs-2.2.0)
  • *NIX: GMT_SHAREDIR/../GSHHS-<some version> (e.g., /usr/local/share/gshhs-2.2.0 and /usr/local/share/gshhs-2.2.0)
    The latter is pretty useless for monolithic installs so all share directories relative to PATH must be searched as well:
  • Foreach DIR in PATH do search in DIR/../share/GSHHS-<some version> (e.g., /opt/local/share/gmt-5.0.1b and /usr/share/gshhs-2.2.0)

Implementing the optional install with cmake is easy, however the features outlined above need some coding and are a necessary step for #18 to function properly. Hence, I suggest for the time being to add a non-default cmake option to avoid installing GSHHS into GMT_SHAREDIR and implement (1-4) and #4 (GSHHS min version checks). Then, (5) has to be addressed to avoid another variable hell.

Last but not least on might consider distributing combined binary packages as well as separate packages on the download page.

RE: GSHHS built-in or separate? - Added by Florian over 5 years ago

As a side-note: The current layout of gshhs-2.2.0.tar.bz2 is not very CMake/distribution friendly:

LICENSE.TXT
README.TXT
share
share/coast
share/coast/binned_border_c.cdf
share/coast/binned_border_f.cdf
[...]
share/coast/binned_river_l.cdf
Everything should be contained in one folder gshhs-<version>:
gshhs-2.2.0/binned_border_c.cdf
gshhs-2.2.0/binned_border_f.cdf
[...]
gshhs-2.2.0/binned_river_l.cdf
gshhs-2.2.0/LICENSE.TXT
gshhs-2.2.0/README.TXT

The current LICENSE.TXT is not GSHHS specific at all. This must be removed completely:

NOTE: As of GMT 4.5.6, GMT is distributed under the GPL version 2 OR LATER.
Below is the text of GPL 2; later version are available from GNU.
Also note that triangle.[ch] has its own license that is NOT GPL.
Users who wishes strict GPL conformance should compile GMT WITHOUT using
the --enable-triangle configure option.
[...]

Also the amount of space needed to store GSHHS on disk could be reduced, e.g.:

$ ncdeflate.sh -sv *.cdf
binned_GSHHS_c.cdf... could not reduce file size. already compressed?
binned_GSHHS_f.cdf... ratio: 39%.
binned_GSHHS_h.cdf... ratio: 35%.
binned_GSHHS_i.cdf... ratio: 32%.
binned_GSHHS_l.cdf... ratio: 25%.
binned_border_c.cdf... could not reduce file size. already compressed?
binned_border_f.cdf... ratio: 47%.
binned_border_h.cdf... ratio: 27%.
binned_border_i.cdf... ratio: 7%.
binned_border_l.cdf... could not reduce file size. already compressed?
binned_river_c.cdf... ratio: 47%.
binned_river_f.cdf... ratio: 35%.
binned_river_h.cdf... ratio: 23%.
binned_river_i.cdf... ratio: 24%.
binned_river_l.cdf... ratio: 34%.
This reduces the overall installed size by 30 MiB (from 82 to 52). For compatibility with netCDF-3 also an uncompressed version should be distributed. Tars should be created with --owner 0 --group 0 since uid and gid will be restored during extraction if tar is run by the root user.

RE: GSHHS built-in or separate? - Added by Paul over 5 years ago

What is the recommended method for moving a subdir from one repository (gmt4) to another (GSHHS+WDBII)? Can this be done with a svn move command or must I give up on the history and copy the coast dir into my working copy of GSHHS+WDBII and add it there as new files...

-p

(1-6/6)