Re: autoconf check for octave version and mex.h?

[John W. Eaton]

On 11-Aug-2004, Dan McMahill <address@hidden> wrote:

| how about a check then that says 'mex is from octave'
| vs 'mex is from matlab'?  Clearly I can do AC_PATH_PROG(MEX, mex)
| to locate a mex program, but I'm not sure how to figure out
| what I've got after that.

If you use mkoctfile to compile your files, it should set the compiler
flags up properly so that the compiler will find Octave's mex.h file.
You could write autoconf tests to check for the existence of
mkoctfile, then use that to see if a test program with the features
you need (mex.h, etc.) are available in the installed version of
Octave that corresponds to the mkoctfile script you found.

| The reason I wanted to look for a version is to be able to setup some
| versioned install directories to make it easier to install a package against
| multiple versions of octave.

The octave-config script should give you what you want.  You still
don't have to look for or actually care about what the specific
version number happens to be, as you can do things like

  $ octave-config --print LOCALVERFCNFILEDIR
  /usr/share/octave/2.1.57/site/m

  $ octave-config --print LOCALVEROCTFILEDIR
  /usr/lib/octave/2.1.57/site/oct/i386-pc-linux-gnu

to find the names of the directories to use for installing your
package.  Then you can do the installation in a subdirectory of those
directories and it will be specific to the version you used for
building your package.

| For example, the scilab frontend for the package in question will
| put stuff in libexec/pkgname-pkgver/scilab-scilabver/*  which lets
| multiple versions of 'pkg' built against multiple versions of 'scilab'
| coexist.  Maybe a bad idea, but I've seen enough pain when some
| big packages have transitioned from one major version to another major
| version and they needed to coexist during a transition period.

I don't think it is a bad idea.  In fact, it is rare that you would be
able to build a .oct file for one version of Octave and have it work
with another.  This feature annoys some people a lot, but until we
have a stable interface to the Octave internals, I don't see a way
around it.  And even if we do arrive at a stable interface, we will
also have to have a stable C++ ABI, otherwise, you would still have
trouble the Octave was compiled with a different C++ compiler (or
version of the same compiler) from the one used to build your package.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------