Re: [Pkg-octave-devel] /usr/bin/mex and texlive

[Paul Kienzle]

On Oct 3, 2006, at 9:36 AM, John W. Eaton wrote:

> On  3-Oct-2006, Paul Kienzle wrote:
>
> | Handing /usr/bin/mex to another package is appropriate.
> |
> | mex is gone from octave2.9-forge and won't pop
> | up in octave since it is an m-file there.
> |
> | The command line form of mex in octave2.9 is "mkoctfile -mex".
>
> Yes, I added the --mex option to mkoctfile because
> is was the easy thing to do.  In Matlab, there is
> a mex command that can be used at the Matlab prompt
> and also a mex shell command, so it might be nice to
> provide a script called mex that has an interface
> the same as the mex shell command provided by Matlab
> so that scripts or Makefiles that people have for
> Matlab will work with Octave too.  But that will
> lead to conflicts, not only with texlive, but also
> with Matlab itself.  I imagine that people would
> not be happy if, after installing Octave, the mex
> command suddenly starts doing something different.
> So I'm not sure what the best solution is.  Maybe
> provide the script in an examples directory but
> not install it by default?

It would be convenient to have a compatible mex
command so that people could more easily use the
makefile when they are using mex code in Octave.
As you say it should not be called mex by default
since that will be a problem for people with matlab
on the path.  Maybe omex?

People without matlab can add an alias to their
startup script:

  alias mex=omex

People with matlab would have to make sure that
the alias is cleared after make is called:

   alias mex=omex; make; unalias mex

This is ugly, but we could hide it in an omake script:

  #!/bin/sh
  alias mex=omex
  make "$*"

Kind of obscure but it will work.

Doing nothing is also a reasonable option; last I
saw, mex files had OS dependent extensions which
means that we will need to change the makefile to
work with octave anyway.

- Paul