reduce-algebra portfile

[Mark Brethen]

I found the url that is used to download the files in an xport.pat file (first line looks like "Master http://www.zib.de/...")in the /psl directory. The portfile uses "fetch.type          svn" to fetch Reduce. Is it permissible to have multiple fetch types in a single portfile?


On Dec 13, 2011, at 12:09 AM, Ryan Schmidt wrote:

> 
> On Dec 13, 2011, at 00:01, Mark Brethen wrote:
> 
>> I finally got it to the build phase using:
>> 
>> pre-build {
>> 	system -W ${worksrcpath}/psl "./make-psl.sh macintel64"
>> }
>> 
>> But the build phase never completed, and I checked the main.log was up to 40 gig so I killed it. The log file was too large to read and figure out what was going on. However, I found the section of the configure script (in /psl) that downloads the binaries from www.zib.de. You mentioned patching the file, so where would you put this? The part of the configure script follows:
>> 
>> ---------
>> # Now I need to build a copy of the "xport" utility. You may view it as
>> # mildly eccentric to build this tool at configure time!
>> 
>> mkdir xport
>> cd xport
>> $srcdir/support-packages/xport-2.05/configure
>> make
>> cd ..
>> 
>> { $as_echo "$as_me:${as_lineno-$LINENO}: Will build this PSL using the $pslver initial binaries" >&5
>> $as_echo "$as_me: Will build this PSL using the $pslver initial binaries" >&6;}
>> 
>> # rm -rf psl
>> mkdir psl
>> cp -r $srcdir/psl-$pslver/* psl
>> 
>> # Now in my new world about the only thing that will have been copied here
>> # will be a file "xport.pat". This can then be used to arrange to fetch the
>> # relevant pre-build PSL binary files from a web-site (www.zib.de) where they
>> # are maintained, and is a scheme adopted here to make thePSL version
>> # available NOW while a full source release is still being worked on.
>> 
>> cd psl
>> { $as_echo "$as_me:${as_lineno-$LINENO}: About to update PSL binaries from master web-site at ZIB" >&5
>> $as_echo "$as_me: About to update PSL binaries from master web-site at ZIB" >&6;}
>> ../xport/xport -fetch
>> # xport.pat should really have "executable bpsl" in it, but in case it does
>> # not I will force executable status here...
>> chmod +x bpsl*
>> cd ..
>> ----------
> 
> You could write a patch that removes the "../xport/xport -fetch" line. If that's all xport is for, you can remove the lines that build xport. Then find the distfile and add it to the MacPorts distfiles variable so MacPorts will fetch it, and add checksums for it to the checksums variable. Decide whether MacPorts should try to decompress this file itself; if not, set "extract.only" to list only the files MacPorts should decompress. In post-extract, you may need to move either the compressed file or the uncompressed result to the place where the configure script wants it to be.
> 
> 
> 
> 



Mark