Remove all Ruby code from the repository

[Stephen Biggs-Fox]

Currently, the Ruby programming language is used for some code generation tasks (e.g. overrides.rb, gs2_init.rb). This is not good because Ruby is not always available on machines that we might use to run gs2 and one needs to have Ruby installed to build Ruby from its git repository (although building from release tarballs seems to work) so we can't always easily get it onto machines that don't have it. Using Python3 is preferable as it is nearly always available as it is usually part of the operating system. Therefore, we should remove all Ruby code from the repository, replacing with Python3 if necessary..

It is questionable whether the code generation provided by Ruby is even required. Therefore, we need to do the following:

1. Investigate whether the code generation currently provided by Ruby is even necessary.

2. (a) If the code generation is not required, then remove it, tidying up the Ruby-related aspects f the build system in the process; or

   (b) if the code generation is required, then replace the Ruby code with Python3 code as Python3 more widely available than Ruby.

3. While we're at it, we should ensure that any automatically generated code is not tracked by git - only the code that does the generation should be tracked. Of course, if the code generation scripts are removed, then the code that it generates does need to be tracked.

[David Dickinson]

On point 3 -- the reason we track the generated code is two fold : 1. So that we don't have to worry about having access to the generator (e.g. ruby here), 2. so PR's will clearly demonstrate what the changes to the source code will be due to the changes in the generating code (as this is often not obvious).

[Stephen Biggs-Fox]

So that sounds like the Ruby stuff is a helper to generate code rather than having to write it all manually, as opposed to a dynamic code generator that updates code with variable information every time it is built, e.g. with current date, git hash, or similar. In which case, it does make sense to track both the code generator and it's output as the output is what we really want to track and the generator is just there as a helper. In this case, we should probably move the generator scripts to the 'scripts' directory or similar. Also, it might be a good idea to remove running of the code generator from the build process. I have no idea what it's generating so I have no idea if this is the right thing to do.

[David Dickinson]

It's in the build process so that if you are developing the code by modifying the ruby it will automatically generate the new source code when you next try to build with make.

[Stephen Biggs-Fox]

OK, that makes sense. But how come the build process was trying to run the Ruby scripts for me on a fresh checkout? Maybe this is something to do with the timestamp of the Ruby files being newer than the Fortran it generates because the files have the timestamp of the git checkout and maybe the generated code was checked out first. Is there anything we can do about this?

[David Dickinson]

I think that is possibly the case -- does it still try to rebuild them if you touch the target source file and then run make?

Probably nothing we can do automatically but you could probably put something in your git hooks if you wanted.

[David Dickinson]

Fixed in 8.1 (aside from a valgrind script)