On Sat, 25 Jun 2005, James R. Phillips wrote: > --- Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
<http://cygwin.com/acronyms/#PCYMTNQREAIYR>. Thanks. > > 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. Ah, yes, that's definitely a complication. I assume the user interaction is required to either find out about the architecture (which is likely available from some tool or another) or to set compilation parameters (for which one could pick reasonable defaults). But the two-hour compilation time is indeed a showstopper (though there were precedents ];-> ). > > 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. Building a DLL isn't hard. Writing a function that dlopen's a DLL and checks for the return value isn't very hard either. This isn't systems-level stuff... It all depends on the amount of time you'd like to invest in this, of course. > > 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. This is not a question of release cycles. If someone reinstalls the current version of lapack, they'll lose the optimized atlas DLLs just as surely as they would on an upgrade. Besides, if there are packaging or Cygwin-specific problems, you may want to make a few Cygwin releases based on the same upstream versions of lapack/atlas, which the users would have to upgrade to. How does the Linux version of atlas handle these issues? Does it use symlinks to shared libraries? > Thanks for your thoughts. You're welcome. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
