cygwin packaging approach for atlas3.6 and lapack3

[James R. Phillips]

--- Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:

> Why not include a postinstall script for atlas that would compile and
> install the executables?

The atlas compilation and optimization process takes up to an hour or two, or
even longer if full optimization is requested.  It also requires user
interaction.  These two features render it unsuitable for a postinstall script.

> Would it be possible to build a helper DLL that would look for and load
> the atlas DLLs dynamically?  That way, you don't have to replace existing
> DLLs (always a shaky proposition).

I dunno.  My best programming language is matlab/octave m-file.  I can write
simple console programs in C, but I have never developed systems software for
windows.

> The problem with your approach is that if you install both the binary and
> the source packages, and then upgrade the binary package, the optimized
> versions will be gone.  I'd prefer the postinstall solution, combined with
> a helper DLL that delegates to either the default or the optimized DLLs.
> 	Igor

Agreed, this is an issue.  It is ameliorated by slow release cycles for atlas
and lapack.  Actually there hasn't been a new lapack release since 2000/05. 
atlas is under active development, but stable releases tend to be a year or
more apart.

Thanks for your thoughts.

Jim Phillips