Here are some of the tools and "tricks of the trade" that I use to maintain LAPACK.
LAPACK is backward compatible. If you need to change the calling sequence to an existing routine, or its amount of workspace, then you MUST create a new routine. You cannot make any change that would break a user's existing code calling LAPACK.
The most useful options to ftnchek are:
ftnchek -declare -noextern -portability -library *.f > ~/listing
For example, if I want to check the s.p.complex and d.p.complex EIG codes (source and testers), I would type:
alias ftnchek 'ftnchek -declare -noextern -portability -library' cd LAPACK/TESTING/EIG ftnchek c*.f z*.f ../../SRC/c*.f ../../SRC/z*.f ~/eig.listingand then view the listing file for errors...
Be aware that d.p.complex is not part of the ANSI standard, so it won't recognize a lot of the COMPLEX*16 stuff, and will thus give a lot of extraneous error messages.
These tools polish the new codes so that they conform to to the LAPACK style. I use the same for LAPACK.
SGI IRIX64 f77 -g -DEBUG:subscript_check=ON -trapuv *.f ALPHA Tru64 f77 -C=all *.f AIX xlf -C *.f Solaris f77 -C *.f
Refer to the release_notes.html file for "machine specific installation hints".
If the code passes these tests, then we say that it can be included in LAPACK.