From: <or...@co...> - 2008-09-03 04:58:50
|
Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml -where". This will allow for the differences in Debian and Fedora (and other) install locations. Debian guidelines: 1.3.2. OCaml Location The root of all installed OCaml libraries is the OCaml standard library directory, which is /usr/lib/ocaml/VERSION/, at the time of writing /usr/lib/ocaml/3.10.2. This location can be obtained from the OCaml compiler by invoking it as ocamlc -where. Fedora: %{_libdir}/ocaml/foolib On x86_64: mock-chroot> ocamlc -where /usr/lib64/ocaml |
From: Andrew R. <and...@us...> - 2008-09-03 07:49:09
|
On Tue, Sep 02, 2008 at 10:58:52PM -0600, or...@co... wrote: > Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml > -where". This will allow for the differences in Debian and Fedora (and > other) install locations. > > Debian guidelines: > > 1.3.2. OCaml Location > > The root of all installed OCaml libraries is the OCaml standard > library directory, which is /usr/lib/ocaml/VERSION/, at the > time of writing /usr/lib/ocaml/3.10.2. This location can be > obtained from the OCaml compiler by invoking it as ocamlc > -where. > > > Fedora: > > %{_libdir}/ocaml/foolib > > On x86_64: > mock-chroot> ocamlc -where > /usr/lib64/ocaml Orion, I discussed this with Hez when implementing the cmake support for ocaml. In my opinion a defaul build should have everything as a subdirectory of the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are installing on a system without root access? What if you are testing different versions? This is what we do for all other languages. For packaging you are right - using "ocaml -where" is the correct thing to do, but this is an issue for the packager. Andrew |
From: <or...@co...> - 2008-09-03 13:52:53
|
> On Tue, Sep 02, 2008 at 10:58:52PM -0600, or...@co... wrote: >> Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml >> -where". This will allow for the differences in Debian and Fedora (and >> other) install locations. >> >> Debian guidelines: >> >> 1.3.2. OCaml Location >> >> The root of all installed OCaml libraries is the OCaml standard >> library directory, which is /usr/lib/ocaml/VERSION/, at the >> time of writing /usr/lib/ocaml/3.10.2. This location can be >> obtained from the OCaml compiler by invoking it as ocamlc >> -where. >> >> >> Fedora: >> >> %{_libdir}/ocaml/foolib >> >> On x86_64: >> mock-chroot> ocamlc -where >> /usr/lib64/ocaml > > Orion, > > I discussed this with Hez when implementing the cmake support for ocaml. > In my opinion a defaul build should have everything as a subdirectory of > the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are > installing on a system without root access? What if you are testing > different versions? This is what we do for all other languages. > > For packaging you are right - using "ocaml -where" is the correct thing > to do, but this is an issue for the packager. > > Andrew Well, I'm the packager, so it's an issue for me :-). Currently there is no way to override OCAML_INSTALL_DIR. I'm happy to pass in -DOCAML_INSTALL_DIR:PATH=`ocamlc -where` to cmake if that's what you guys decide, but I need to be able to set it. - Orion |
From: Andrew R. <and...@us...> - 2008-09-03 14:53:31
|
On Wed, Sep 03, 2008 at 07:52:55AM -0600, or...@co... wrote: > > On Tue, Sep 02, 2008 at 10:58:52PM -0600, or...@co... wrote: > >> Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml > >> -where". This will allow for the differences in Debian and Fedora (and > >> other) install locations. > >> > >> Debian guidelines: > >> > >> 1.3.2. OCaml Location > >> > >> The root of all installed OCaml libraries is the OCaml standard > >> library directory, which is /usr/lib/ocaml/VERSION/, at the > >> time of writing /usr/lib/ocaml/3.10.2. This location can be > >> obtained from the OCaml compiler by invoking it as ocamlc > >> -where. > >> > >> > >> Fedora: > >> > >> %{_libdir}/ocaml/foolib > >> > >> On x86_64: > >> mock-chroot> ocamlc -where > >> /usr/lib64/ocaml > > > > Orion, > > > > I discussed this with Hez when implementing the cmake support for ocaml. > > In my opinion a defaul build should have everything as a subdirectory of > > the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are > > installing on a system without root access? What if you are testing > > different versions? This is what we do for all other languages. > > > > For packaging you are right - using "ocaml -where" is the correct thing > > to do, but this is an issue for the packager. > > > > Andrew > > Well, I'm the packager, so it's an issue for me :-). Currently there is > no way to override OCAML_INSTALL_DIR. I'm happy to pass in > -DOCAML_INSTALL_DIR:PATH=`ocamlc -where` to cmake if that's what you guys > decide, but I need to be able to set it. Orion, You can already set OCAML_INSTALL_DIR on the cmake command line as you describe. It might not be documented, but it does work. At least it did work with cmake2.4 when I tested it. Andrew |
From: Alan W. I. <ir...@be...> - 2008-09-03 14:58:21
|
On 2008-09-03 08:49+0100 Andrew Ross wrote: > On Tue, Sep 02, 2008 at 10:58:52PM -0600, or...@co... wrote: >> Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml >> -where". This will allow for the differences in Debian and Fedora (and >> other) install locations. >> >> Debian guidelines: >> >> 1.3.2. OCaml Location >> >> The root of all installed OCaml libraries is the OCaml standard >> library directory, which is /usr/lib/ocaml/VERSION/, at the >> time of writing /usr/lib/ocaml/3.10.2. This location can be >> obtained from the OCaml compiler by invoking it as ocamlc >> -where. >> >> >> Fedora: >> >> %{_libdir}/ocaml/foolib >> >> On x86_64: >> mock-chroot> ocamlc -where >> /usr/lib64/ocaml > > Orion, > > I discussed this with Hez when implementing the cmake support for ocaml. > In my opinion a defaul build should have everything as a subdirectory of > the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are > installing on a system without root access? What if you are testing > different versions? This is what we do for all other languages. I think a good compromise here is to use "ocamlc -where" results but with the install prefix substituted for the system prefix. IIRC, this is what we do in the python case where we also have to deal with versioned and distribution dependent install directories. The result would be $prefix/lib/ocaml/3.10.2 on Debian and $prefix/lib64/ocaml on Fedora so both sets of packagers get the right result automatically when $prefix is /usr, and users who want/need a non-root install prefix are allowed to have one. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hc...@at...> - 2008-09-03 16:58:46
|
On Wed, Sep 3, 2008 at 10:58 AM, Alan W. Irwin <ir...@be...> wrote: > On 2008-09-03 08:49+0100 Andrew Ross wrote: > >> On Tue, Sep 02, 2008 at 10:58:52PM -0600, or...@co... wrote: >>> Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml >>> -where". This will allow for the differences in Debian and Fedora (and >>> other) install locations. >>> >>> Debian guidelines: >>> >>> 1.3.2. OCaml Location >>> >>> The root of all installed OCaml libraries is the OCaml standard >>> library directory, which is /usr/lib/ocaml/VERSION/, at the >>> time of writing /usr/lib/ocaml/3.10.2. This location can be >>> obtained from the OCaml compiler by invoking it as ocamlc >>> -where. >>> >>> >>> Fedora: >>> >>> %{_libdir}/ocaml/foolib >>> >>> On x86_64: >>> mock-chroot> ocamlc -where >>> /usr/lib64/ocaml >> >> Orion, >> >> I discussed this with Hez when implementing the cmake support for ocaml. >> In my opinion a defaul build should have everything as a subdirectory of >> the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are >> installing on a system without root access? What if you are testing >> different versions? This is what we do for all other languages. > > I think a good compromise here is to use "ocamlc -where" results but with the > install prefix substituted for the system prefix. IIRC, this is what we do > in the python case where we also have to deal with versioned and > distribution dependent install directories. > > The result would be $prefix/lib/ocaml/3.10.2 on Debian > and $prefix/lib64/ocaml on Fedora so both sets of packagers get the > right result automatically when $prefix is /usr, and users who want/need > a non-root install prefix are allowed to have one. I have CC'd Richard Jones on this message. He has done the packaging for most of the available Fedora OCaml RPMs and can hopefully provide some input. Another option may be to add a "make ocaml-findlib-install" or similar OCaml specific target. The ocamlfind [1] tool provides a means to cleanly (un)install OCaml libraries and ease their use in compilation and linking of OCaml programs. This could potentially be useful both for people who have OCaml installed in a non-standard location and possibly for packagers as well. Or perhaps at least one of the OCaml packages in Fedora (the Cairo bindings) uses ocamlfind for installation of the package files according to the package SPEC file. My cmake knowledge is still extremely limited, but I would be happy to assist where I am able. Hez [1] - http://projects.camlcity.org/projects/findlib.html -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Orion P. <or...@co...> - 2008-09-03 15:29:56
|
Andrew Ross wrote: > Orion, > > You can already set OCAML_INSTALL_DIR on the cmake command line as you > describe. It might not be documented, but it does work. At least it did > work with cmake2.4 when I tested it. I guess I still don't really understand cmake. I thought a SET command in the cmake files wasn't overridden by the command line, but I guess it is. Sorry about that. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Andrew R. <and...@us...> - 2008-09-03 16:12:41
|
On Wed, Sep 03, 2008 at 09:29:53AM -0600, Orion Poplawski wrote: > Andrew Ross wrote: > > Orion, > > > > You can already set OCAML_INSTALL_DIR on the cmake command line as you > > describe. It might not be documented, but it does work. At least it did > > work with cmake2.4 when I tested it. > > I guess I still don't really understand cmake. I thought a SET command > in the cmake files wasn't overridden by the command line, but I guess it > is. Sorry about that. It is because the variable is a cache entry. The -D option override the default values for a cache entry. (Correct me if I'm wrong Alan!) Andrew |
From: Orion P. <or...@co...> - 2008-09-03 16:22:39
|
Andrew Ross wrote: > On Wed, Sep 03, 2008 at 09:29:53AM -0600, Orion Poplawski wrote: >> Andrew Ross wrote: >>> Orion, >>> >>> You can already set OCAML_INSTALL_DIR on the cmake command line as you >>> describe. It might not be documented, but it does work. At least it did >>> work with cmake2.4 when I tested it. >> I guess I still don't really understand cmake. I thought a SET command >> in the cmake files wasn't overridden by the command line, but I guess it >> is. Sorry about that. > > It is because the variable is a cache entry. The -D option override the > default values for a cache entry. (Correct me if I'm wrong Alan!) > > Andrew That looks to be it. I'm still tracking down some Fedora rawhide sgml issues, but it looks like I'm going to need to override XML_DECL, so: --- plplot-5.9.0-svn8745/cmake/modules/docbook.cmake.doc 2008-05-06 20:20:57.000000000 -0600 +++ plplot-5.9.0-svn8745/cmake/modules/docbook.cmake 2008-09-03 09:36:44.000000000 -0600 @@ -49,7 +49,7 @@ set(PLPLOT_WEBSITE "plplot.sourceforge.net" CACHE STRING "PLplot web site") # Required for validation regardless of whether BUILD_DOC is set -set(XML_DECL /usr/share/xml/declaration/xml.dcl) +set(XML_DECL /usr/share/xml/declaration/xml.dcl CACHE FILEPATH "Location of xml.dcl") set(DOCBOOK_DTD_PUBID "-//OASIS//DTD DocBook XML V4.2//EN") find_program(ONSGMLS onsgmls) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Andrew R. <and...@us...> - 2008-09-03 16:23:29
|
On Wed, Sep 03, 2008 at 07:58:01AM -0700, Alan Irwin wrote: > On 2008-09-03 08:49+0100 Andrew Ross wrote: > > >Orion, > > > >I discussed this with Hez when implementing the cmake support for ocaml. > >In my opinion a defaul build should have everything as a subdirectory of > >the install tree prefix (CMAKE_INSTALL_PREFIX). What if you are > >installing on a system without root access? What if you are testing > >different versions? This is what we do for all other languages. > > I think a good compromise here is to use "ocamlc -where" results but with > the > install prefix substituted for the system prefix. IIRC, this is what we do > in the python case where we also have to deal with versioned and > distribution dependent install directories. > > The result would be $prefix/lib/ocaml/3.10.2 on Debian > and $prefix/lib64/ocaml on Fedora so both sets of packagers get the > right result automatically when $prefix is /usr, and users who want/need > a non-root install prefix are allowed to have one. Alan, Sounds like a good potential compromise. This is easy on UNIX where there is a default /usr prefix. How will this work on other platforms where we don't necessarily know what the prefix is, or even for cases where ocaml is installed in a non-standard location? The python sysconfig.get_python_lib function allows you to specify a prefix and it will return a full library path. This makes life much simpler. Andrew |
From: Alan W. I. <ir...@be...> - 2008-09-03 17:20:08
|
On 2008-09-03 17:23+0100 Andrew Ross wrote: > On Wed, Sep 03, 2008 at 07:58:01AM -0700, Alan Irwin wrote: >> I think a good compromise here is to use "ocamlc -where" results but with >> the >> install prefix substituted for the system prefix. IIRC, this is what we do >> in the python case where we also have to deal with versioned and >> distribution dependent install directories. >> >> The result would be $prefix/lib/ocaml/3.10.2 on Debian >> and $prefix/lib64/ocaml on Fedora so both sets of packagers get the >> right result automatically when $prefix is /usr, and users who want/need >> a non-root install prefix are allowed to have one. > > Alan, > > Sounds like a good potential compromise. This is easy on UNIX where there > is a default /usr prefix. How will this work on other platforms where we > don't necessarily know what the prefix is, or even for cases where ocaml > is installed in a non-standard location? Well when I wrote the above I was thinking along the lines of a CMake regex to find lib.*/ocaml.* in the directory string and replace everything above that with the installation prefix. That would certainly work in the above two cases. I cannot guarantee it will work in all cases until we get more user feedback. Of course, there is also the alternative of creating a CMake option to install exactly in the location given by ocamlc -where. If you prefer that optional approach to the regex approach, that is fine with me. To answer your question about overriding cached variables versus uncached variables using -D options, my own opinion is that is problematic because I believe the behaviour changed somewhere late in the 2.4.x series or between 2.4.8 and 2.6.0, and I think the behaviour also depends on whether you provide a variable type to the the -D option or not. Therefore, I think we should deal with this issue explicitly rather than asking the user to override certain CMake variables with -D options. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2008-09-04 20:41:34
|
Richard W.M. Jones wrote: > If you need any help on Fedora packaging, please let me know (I'm not > subscribed to this list). Richard - Could you take a quick look at the plplot scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=806897 and see if the ocaml parts are packaged properly? Thanks! Also, looks like ocaml tests are failing on ppc64. Any thoughts there would be helpful. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2008-09-04 21:32:30
|
Richard W.M. Jones wrote: > On Thu, Sep 04, 2008 at 02:41:40PM -0600, Orion Poplawski wrote: >> Richard W.M. Jones wrote: >>> If you need any help on Fedora packaging, please let me know (I'm not >>> subscribed to this list). >> Richard - >> >> Could you take a quick look at the plplot scratch build here: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=806897 >> >> and see if the ocaml parts are packaged properly? Thanks! > > The name needs to be ocaml-plplot-*. > Use '%package -n ocaml-plplot' etc. to do this. Hmm, how about a Provides: ocaml-plplot = %{version}-%{release}?. All the other packages are "plplot-<lang>". > /usr/lib/ocaml/stublibs/dllplplot_stubs.so needs to be in the main > package, not the -devel subpackage. Done. > >> Also, looks like ocaml tests are failing on ppc64. Any thoughts there >> would be helpful. > > This is the failure, but I've got no idea. If you email David > Woodhouse (dwmw2/infradead.org) he may be able to give you an account > on his ppc64 machine where you can actually try out the test and see > what is segfaulting. Yeah, I've got one ;-( -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |