Re: Distinguish MEX files for different architectures

[John W. Eaton]

On 28-Jun-2011, Jordi Gutiérrez Hermoso wrote:

| Just out of curiousity, how would you handle outside of Matlab and
| Octave a comparable problem about "compiling once, run anywhere," in
| the lingo of Java advertising? Suppose you had some pure C++ code that
| needed to be run in clusters. Would you also use different filename
| extensions?
| 
| The filename extension thing to me seems like an ugly hack. I've only
| ever seen it done with mex files. There aren't .exe64 or .dll64 or
| .so64 filename extensions in common use, so why does Matlab do it?

Handling multiple architectures without having to have completely
separate installations is a nice thing.  However, I think that having
all the binary files for different architectures in a single directory
conflicts with the filesystem hierarchy standard, which as I
understand it would have you put the files for different architectures
in separate directories.  That's what we currently do with .oct files
in the typical Octave installation.  But that doesn't work well if a
given package or "toolbox" contains a mixture of .m and .mex files, or
if you want to have a class method or private function implemented
using a MEX file.  Since @CLASSNAME and private directories are not
mentioned explicitly in the search path, it would complicate things if
they were stored in a separate directory tree.

| Surely it suffices to compile the code for the architecture you're
| going to run it in?

I used to regularly work in environments where my home directory was
shared among a group of systems with different architectures.  It is
nice to have some way of dealing with that.  For individual programs,
I always had separate directories for each type of system and then set
the PATH appropriately in a login script.  But as I said above, this
doesn't work well for MATLAB given the existence of @CLASSNAME and
private directories and the rules about preferring MEX files over .m
files.

| I guess we could patch Octave to recognise .oct64, .octmips, and
| .octw32, octw64 extensions, but this seems a little ugly.

If we want to allow a mixture of .oct/.mex and .m files to function as
expected in multiple architecture environments, then yes, I think we
have to allow this.

I think that .mex still works in Matlab, but the architecture-specific
name is preferred if both are present.  Can someone with Matlab verify
that?

Maybe it would be best to discuss the details of any changes like this
on the maintainers mailing list.

jwe