This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]