search

GenericMappingTools / gmt

The Generic Mapping Tools
https://www.generic-mapping-tools.org
Other
843 stars 352 forks source link

Bash script for building the GMT master branch #3184

Closed seisman closed 4 years ago

seisman commented 4 years ago

Description of the problem

GMT already has many interfaces, GMT/Matlab, PyGMT, GMT.jl and 3rd-party supplements, e.g. gsfml, mbgmt and mbsystem. Ideally, these interfaces and supplements should run a nightly/weekly/monthly CI job against the GMT master branch, to make sure changes in the upcomming GMT releases don't break them. The CI job needs a bash script to download and build GMT. To avoid maintaining the same script in different repositories, it's better that the GMT repository can provide a bash script.

The bash script contains the following steps:

Assuming we have the script ci/build-gmt-master.sh, then other repository can easily install GMT by a command like

curl -sSL https://raw.githubusercontent.com/GenericMappingTools/gmt/master/ci/build-gmt-maste.sh | bash

The script should accept some environmental variables so that other users can control the installation locations and other details.

seisman commented 4 years ago

Any thoughts? @PaulWessel @joa-quim @leouieda @weiji14

PaulWessel commented 4 years ago

It is a good idea. At the moment, there is no such checking for GMT/MEX (but I think JL and I are on top of that), GMT.jl (JL discovers trouble manually and then yells at me), MB-system (I am guessing they don't do CI), gsfml (me again, no CI for that small thing). So probably only pyGMT is ready to take advantage of such a script in a CI. It would be helpful if the MB folks could try someting like this since they use many low-level gmtdev library calls that are undocumented and not guaranteed to stay the same, and hence their source code has lots of #ifdefs for different GMT versions when these things have changed. At least with the proposed script they would know right away if we broke something for them,

weiji14 commented 4 years ago

Yes that would be great. Ties in with what you mentioned at https://github.com/GenericMappingTools/pygmt/issues/345. My only two cents would be to 1) Extend it to Windows (make a .bat file?), and 2) have a way to track the version installed from master (would gmt --version give the git hash?) so that we can trace back to when things broke.

joa-quim commented 4 years ago

GMT.jl already uses GMT master to run its tests.

seisman commented 4 years ago

1) Extend it to Windows (make a .bat file?), and

Having a bat file for Windows is a little challenging, because we need to build all GMT dependent libraries before building GMT on Windows.

2) have a way to track the version installed from master (would gmt --version give the git hash?) so that we can trace back to when things broke.

Yes, for any developing versions, gmt --version reports both the hash and date of the latest commit, e.g. 6.1.0_95f5c4a_2020.04.27.

GMT.jl already uses GMT master to run its tests.

Then the GMT.jl CI script can be simplified a little bit.

leouieda commented 4 years ago

@seisman I think that's a great idea. This is also useful for the Linux users out there that don't have an easy way of upgrading.

seisman commented 4 years ago

Done in #3193.