Installation from source
(→Hacking Miriad (old build style))
(→Hacking Miriad (new build style))
|Line 69:||Line 69:|
== Hacking Miriad (new build style) ==
== Hacking Miriad (new build style) ==
Revision as of 21:43, 26 March 2009
For a few popular architectures we also make miriad binary releases available. They don't always work if your shared libraries are not exactly the same as the ones Miriad had been built with. In that case the procedure below should be tried, but please make sure you have all the required libraries (X11), shells (csh) etc.etc.
Installation from Source
In a nutshell grab the (CVS enabled) source code, and run the install script. If that fails, you should consult the more detailed installation guidelines. You can also follow the new Autoconf based installation.
Step 1: grab the source code
curl ftp://ftp.astro.umd.edu/progs/carma/miriad.tar.gz | tar zxf - or wget -O - ftp://ftp.astro.umd.edu/progs/carma/miriad.tar.gz | tar zxf -
And change directory to the new miriad source tree:
It is quite possible this tar file is out of date with CVS, so you can follow this with an update:
cvs login cvs update
Step 2-old: install using your own default compiler
This shell script does have some optional arguments, but you should not need to supply any. If things look bad, you can have a look at some known installation problems or suggestions how to fix them.
Step 2-new: If you really want to be experimental and try the new autoconf based install, you can also try this hack:
install/test_a_new_miriad_cvs rootdir=. reuse=1 auto=1
Step 3: Source the appropriate startup file, depending on your shell, and miriad should now be usable in your shell. You can also make this permanent by adding this to your ~/.cshrc or ~/.bashrc file.
For example, for a csh style shell in the old build style:
will add miriad to your current (csh) shell. Or if you were using the new build system:
Step 4: If you think MIRIAD is running, you should try some sanity tests.
Hacking Miriad (old build style)
An example of hacking a routine where a user ran into a program that had some kind of obvious problem. In this example we assume the user has write permission in the $MIR tree.
% smauvspec .... # oh oh ... program crashes for probably simple reason ### Fatal Error: Buffer overflow(points), when accumulating plots % mirboss # become more powerful miriad boss (to make mods) % cd $MIRPROG/sma # go to where the action is (yes, you'll have to know that) % cvs -nq update smauvspec.for # for sanity, check if there is no update % cvs update smauvspec.for # if there was, probably good idea to update % mir.prog smauvspec # sanity check: make sure it still compiles % edit smauvspec.for # make your changes in your favorite editor % mir.prog smauvspec # compile your version, it will be in $MIRBIN % cd- # go to where you were working.... % smauvspec vis=..... # check it out
If the user had no permission to write inside the $MIR tree, you could still work around this if your local friendly miriad hacker is not available:
% cp $MIRPROG/sma/smauvspec.* . # make a local copy of the two files you need % edit smauvspec.for # edit it % mirmake smauvspec # uses template makefile. The "debug" command ok as well % ./smauvspec vis=... # test your local version explicitly
The next time when you update miriad (e.g. cvs update, or the more rigorous mirupdate command) it will attempt to merge your modification with any possible modification that were made in the official miriad release. This merge usually works, and you should check this by recopiling that program manually. Or simply use the cvs diff command:
% cd $MIRPROG/sma # go to where the action is % cvs -nq update # watch if smauvspec.for or .h have any C's or U's % cvs diff smauvspec.for # difference yours with the CVS master version % cvs diff -Dnow smauvspec.for # difference if you saw a 'U' in the update test