 |
 |
On Wed, 9 Mar 2005, Malcolm J. Currie wrote: > > Malcolm, this means that you'll probably need to grab some Perl modules from > > our CVS repository. > > Weren't the perlmods and Starperl going into the Starlink repository? > Yes. But I can't work out how to do it. First problem is perl. It doesn't use gnu configure but it has a Configure script and a configure.gnu wrapper that recognizes common gnu-isms. I considered renaming configure.gnu to 'configure' so that it would look like a normal import but then realised that Configure and configure would clash on OSX. I'm loathe to move Configure to Configure.perl and configure.gnu to configure but it looks like that's the best way of retaining the feel of the other packages without being forced to run configure each time someone types 'make'. Next up is PERLMODS. Should we upload untarred versions of the CPAN modules to CVS? Or the tar balls themselves? How do we trigger the 'perl Makefile.PL' step? [which is the equivalent of configure, so maybe we create a configure sh script that does the perl Makefile.PL, but how does it know which PERL to use?] Finally the Starlink modules have to be transferred directly from JAC CVS. We will again need to use the configure-calls-Makefile.PL trick and the Makefile.PLs should be adjusted to recognize the 'check' target as an alias for 'test'. Does all this sound plausible? [it's easier now that I'm composing the email]. It seems the perl module wrapper configure script will have to just assume that $STARCONF_DEFAULT_PREFIX/Perl/bin/perl is to be used first. [Should we install into $STARLINK/Perl or use a more normal $STARLINK/perl ? I suppose backwards compatibility will insist on $STARLINK/Perl but we should add $STARLINK/Perl/bin to the end of the path]. -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj