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:

Are there any other official packages that install to /opt?  I don't have an
/opt at all in my cygwin directory tree.  I am reluctant to create a new
top-level directory just for part of one package.

Not yet. IIRC, the existence of /opt has gotten the go-ahead approval from cgf (& Corinna?) -- but to date, nobody has wanted to be the first to "split off" from the main /usr tree. And that's a GOOD thing...


From the original post where I raised the issue:
http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00305.html

"Now, if adopted, I believe that the /opt tree should be RARELY used. I
hope we don't see an explosion of official cygwin packages that use it;
MOST packages should continue to go into /usr (or /usr/X11R6/) as before. Right now, the only candidates for /opt that I can think of are:
kerberos, cvsnt, and the "gnu tool replacements" that ship with ast-ksh."


There was a fair bit of discussion concerning ast-ksh and its tools about six months ago (maybe longer), but I believe that those folks decided to (a) keep their cygwin packages of ast-ksh separate from our mirror system (b) install directly into /usr/bin. But I could be wrong.

My old (unsupported, unofficial) kerberos port doesn't install into /opt, but if I ever get around to spinning a new version it will go there.

In answer to a question you asked later in the thread concerning man pages and such, it's all spelled out in the FHS -- but I quote again from the above listmessage:

------- begin quote -------
For more information on the /opt heirarchy, see

http://www.pathname.com/fhs/2.2/fhs-3.12.html

Basically, a package to be installed under /opt creates an entire tree:
/opt/<package>/bin
/opt/<package>/lib
/opt/<package>/share
/opt/<package>/man
/opt/<package>/info
/opt/<package>/etc (*)
/opt/<package>/var (**)

(*)  contents may be targets of symlinks originating in /etc/opt/
(**) may be a symlink to /var/opt/<package>/

The package will look for its config files (if any) in
/opt/<package>/etc/ (e.g. --sysconfdir=/opt/<package>/etc/), the symlinks from /etc/opt are placed there to assist the sysadmin.


There's also an optional /opt/bin, /opt/man, /opt/... set of directories
that can OPTIONALLY contain symlinks back to
/opt/<package>/bin/myprog.exe, to prevent PATH / MANPATH / INFOPATH
explosion.  BUT, packages installed into /opt/<package>/ MUST work
properly even without /opt/bin & friends.
------- end quote -------


Not that this couldn't work. What were down to is just a preference. Somewhere in opt would work; so would /usr/lib/lapack.

However, I have no objections if you want to use /usr/lib/lapack/ instead. I assume the "roll your own optimized DLLs from -src package" procedure will end up putting the new DLLs in...


/usr/bin ?

Will that also replace the import libs (and pseudo-staticlib symlinks to them) in /usr/lib/ ? Or is the DLL interface absolutely unchanged by this recompile, so that the "old" import libs are "still good"?

--
Chuck

P.S. I've had some experience with LAPACK and ATLAS on other platforms, so I know the trouble it can often be to get this beastie to compile correctly -- and optimally. Kudos for taking on this task!!


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