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: Jordi Gutiérrez Hermoso
Subject: Re: what to do about dependencies?
Date: Fri, 6 Jan 2012 12:37:10 -0500

On 6 January 2012 11:36, John W. Eaton <address@hidden> wrote:
> People often complain that building Octave is too complicated.

I don't know if building itself is complicated any more than it is for
any other program using the GNU build system. I think the biggest
complaint is that it takes too long. I wish we could improve this. I
remember a couple of years ago, building Octave didn't take so long,
and I don't think it takes longer now because our codebase is so
large. Admittedly, it may be gcc's fault. The times I've tried
building with clang, it seemed faster (but sadly, I couldn't succeed
with a clang build). I seem to recall that libtool was a big culprit
in slowing down the build, so perhaps this really can't be helped
unless we improved libtool itself.

> 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.

I don't like this idea, if you mean having a giant tarball with all
that extraneous stuff inside it. I wouldn't mind having a separate
suggested dependencies tarball with everything in it, perhaps even
with some sort of script that attempts to build and install everything
inside that tarball... but I think the real problem is that most of
our external dependencies aren't very well suited to being built
outside of a Unix-like environment (I'm still thinking Windows is the
biggest problem).

I'm not sure if finding dependencies is the issue people are having.
Building them seems to be the problem, so if we want to alleviate this
situation, we would have to fix the build systems of the dependencies?
This seems like a lot of boring work.

- Jordi G. H.


reply via email to

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