[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: best way to use new qrupdate version?
From: |
Jaroslav Hajek |
Subject: |
Re: best way to use new qrupdate version? |
Date: |
Fri, 9 Oct 2009 08:05:51 +0200 |
On Thu, Oct 8, 2009 at 10:06 PM, John W. Eaton <address@hidden> wrote:
> On 8-Oct-2009, Jaroslav Hajek wrote:
>
> | in version 1.1, which I intend to release later this year, qrupdate
> | will be able to compute rank-1 updates of LU and pivoted LU
> | factorizations. The SVN version already has the functionality. I want
> | to make the feature again available to Octave via a "luupdate"
> | function. The bulk of the code for Octave is already upstream:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/6f3ffe11d926
> |
> | Because there is 100% backward compatibility, I would like Octave stay
> | buildable with qrupdate 1.0, which by now has already spread to
> | several distros. The approach I've taken in the above patch is simply
> | check for one of the new functions after qrupdate was detected, and
> | define an additional macro. But maybe that is not the best idea? Does
> | anyone see a better way?
> | qrupdate uses a F77-style implicit interface, so there is no header
> | file, which could define a versioning symbol.
>
> Couldn't you define a function that returns a version string? But
> even if you did that, I think a version test is not really a
> desirable thing to do in a configure script, and doing it with a
> function requires running a program, not just linking, so that can
> cause trouble for cross compiling (if that even matters for us).
>
> | An alternative is to make qrupdate 1.1 a requirement for Octave 3.4,
> | but it seems nice to support the old version if it's compatible.
>
> I guess the choice is yours. Qrupdate is small and easy to build
> though, isn't it? So it would not be a big burden to require the new
> version. OTOH, if the older version will work (possibly with some
> loss of functionality) then continuing to allow its use would be OK
> with me.
>
> To check in configure, you could do something like this (untested):
>
> save_LIBS="$LIBS"
> LIBS="$BLAS_LIBS $FLIBS $LIBS"
> OCTAVE_CHECK_LIBRARY(qrupdate, qrupdate,
> [qrupdate not found. The QR & Cholesky updating functions will be slow.],
> [],
> [F77_FUNC(sqr1up,SQR1UP)],
> [], [don't use qrupdate, disable QR & Cholesky updating functions],
> [warn_qrupdate=
> AC_CHECK_FUNCS([F77_FUNC(other_qrupdate_fcn,OTHER_QRUPDATE_FCN)],
> [AC_DEFINE(HAVE_OTHER_QRUPDATE_FCN, 1)],
> [warn_qrupdate="other_qrupdate_fcn missing; some loss of functionality"])])
> LIBS="$save_LIBS"
>
> jwe
>
It's close to what I did, except that I split the tests based on
$octave_qrupdate_ok defined from the first test.
If that's OK, I'll leave it as it is.
regards
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz