octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what to do about dependencies?


From: Orion Poplawski
Subject: Re: what to do about dependencies?
Date: Sun, 08 Jan 2012 11:33:30 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/06/2012 09:36 AM, John W. Eaton wrote:
People often complain that building Octave is too complicated.  The
problem is usually that it is too hard to get dependencies installed,
and we don't even have a complete statement of what dependencies are
needed or where to get them.  One only finds out by running configure.

I've tried to help improve that situation slightly with the following
patch to document the dependencies and where to find their sources:

   http://hg.savannah.gnu.org/hgweb/octave/rev/87f06b9990bb

I'm not pretending that this is perfect or complete, but it is a
start.

For the future, I think we should consider including at least the
required dependencies (GNU Readline, PCRE, BLAS+LAPACK (ATLAS?)) and
all numerical library dependencies (ARPACK, FFTW3, GLPK, Qhull,
QRUPDATE, and SuiteSparse) with Octave.  Then we could arrange for the
configure script to automatically fall back to the included packages
if these libraries are not already installed, or if there is some
problem with them that would prevent them from being used.  There
could also be a summary message from configure explaining that this is
happening so that the user would have a chance to fix the system
problems and run configure again instead of just using the included
software.

I'm not sure whether we should consider including other libraries as
well.  The cURL, HDF5, and zlib libraries might be fairly easy, but
something like GraphicsMagick++ itself requires several more libraries
and I don't think we want to attempt including everything down to the
level of the C library (!).  But the list above would go a long way to
avoiding the complaints we see about how hard it is to build Octave
and dependencies.  At least running configure and make would work and
build a copy of Octave that would run, though perhaps without graphics
capabilities.

We could also have configure options to force the included libraries
to be used instead of the system libraries.  That way we would be able
to point to a set of package versions that are known to work.

I'm not proposing that we do this for the 3.6.0 release, but that we
consider it for 3.8.0.

Comments?

jwe

Speaking as a distribution packager, it is a pain to have to review and strip out bundled libraries out of a package. If you do wish to pursue this route, I would strongly suggest making the bundled libraries a separate tarball that could be unpacked into the octave directory.

Orion

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  address@hidden
Boulder, CO 80301              http://www.cora.nwra.com


reply via email to

[Prev in Thread] Current Thread [Next in Thread]