lapack 3.0 (OpenGL and ncurses maintainers please take note)

[Charles Wilson]

James R. Phillips wrote:
> --- Corinna Vinschen wrote:
>>It would help to keep everything in one place.  As I said, I'm also
>>ok with using /usr/lib/lapack, but using /opt here looks neater to me.
> 
> Um, since you give me the option of keeping it as is, I'm going to do that.  I
> need to press on to getting octave packaged (the goal of the whole excercise).

As I stated in my earlier message, I've no objections to /usr/lib/lapack 
-- you're the maintainer.  However, there are a few nits:

(1) aren't there some header files that need to be packaged, as well?
(2) the documentation directory should't include the REL number (e.g.
     /usr/share/doc/lapack-3.0/  not  /usr/share/doc/lapack-3.0-1/
(3) ditto the cygwin specific README
     /usr/share/doc/Cygwin/lapack-3.0.README

(I *said* they were nits)

I would also mention that you might (but I doubt it; see below) find it 
necessary to adopt the "typical" DLLPkg-mainPkg-develPkg separation...

lapack-X.Y.Z-REL
    /etc/profile.d/*
    /usr/share/doc/CYGWIN/*
    /usr/share/doc/lapack-X.Y.Z/lapack/*
    /usr/share/doc/lapack-X.Y.Z/blas/*
    /usr/share/man/*
    /usr/share/info/*

liblapackN-X.Y.Z-REL
    /usr/lib/lapack/cygblas-N.dll
    /usr/lib/lapack/cyglapack-N.dll

lapack-devel-X.Y.Z-REL
    /usr/include/lapack/*
    /usr/include/blas/*
    /usr/include/*
    /usr/lib/lapack.dll.a
    /usr/lib/blas.dll.a
    /usr/lib/lapack.a
    /usr/lib/blas.a

This is necessary, if, for instance, the blas or lapack interface 
changes, and you want to release a new version of the DLLs -- but some 
people might be using your old octave, or *some other client they 
compiled themselves which you do not control* which needs the old 
interface and the old DLLs.  If they blindly upgrade to the "new" 
package, without any safegaurds like this 
DLL-in-separate-package-with-vernums scheme (liblapackN not liblapack; 
cyglapack-N.dll not cyglapack.dll), then that upgrade will break their 
clients.

You only bump the DLLnum when existing DLL entrypoints are modified or 
removed; not merely when new entrypoints are added.  Now, blas and 
lapack are highly stable, and I doubt their interface will change at 
all.  BUT, I have had to "bump" DLL numbers in the past due to OTHER 
circumstances, like the grand cygwin 1.3.xx-TO-1.5.xx transition, or 
because I changed calling conventions ( stdcall vs. cdecl vs. fastcall? 
  You might actually want to look at fastcall for efficiency...but you'd 
be pioneering on cygwin AFAIK. )

The worst example was when I had to change the interface of ncurses 
MYSELF, even though the upstream package didn't:  it had long exported 
data items that weren't effectively handled by the pseudo-reloc code 
(see 'info ld').  However, a new release of ncurses ADDED an entrypoint, 
which caused clients via macros to access this DATA export; common 
clients had never before accessed this DATA export, so I never knew 
there was a problem with it.  To correct the issue, I added an accessor 
method instead and stopped trying to export the DATA directly.  This 
required header file changes to fool upstream clients into using my 
accessor...and obviously they had to recompile and relink against the 
new DLL version: I had changed an existing interface.

But until the other maintainers released recompiled versions, I didn't 
want every ncurses-using client to break, so both DLLs had to coexist on 
the user's machine.  Hence, the DLLnum for ncurses is up to 8 now.  Sigh.

Back on point: regardless, you do NOT need to do anything this fancy 
right now.  In fact, you may never need to -- since lapack/blas is so 
stable.

But header files might be important. :-)

--
Chuck