Re: mex files for different architectures

[Moritz Borgmann]

> On 22-Mar-2008, Xavier Delacour wrote:
>
> | Glancing at pkg.m, it should be possible to construct a package with
> | the following structure:
> |
> | tar tzf myfunc-1.0.tar.gz
> | myfunc-1.0/
> | myfunc-1.0/DESCRIPTION
> | myfunc-1.0/inst/
> | myfunc-1.0/inst/i486-pc-linux-gnu-api-v24/
> | myfunc-1.0/inst/i486-pc-linux-gnu-api-v24/myfunc.mex
> | myfunc-1.0/inst/another-arch/
> | myfunc-1.0/inst/another-arch/myfunc.mex
> | myfunc-1.0/COPYING
> | myfunc-1.0/PKG_ADD
> | myfunc-1.0/INDEX
> |
> | Octave will load (pkg.m will call addpath on) the appropriate
> | directory based on its arch.
> | arch = strcat(octave_config_info("canonical_host_type"), "-",
> | octave_config_info("api_version"))
> |
> | That's one way to do it. I don't imagine arch-dependent mex/oct
> | suffixes are difficult to implement, but I have not looked closely.
> | Calling addpath yourself based on arch (as you suggest) is probably
> | the easiest way to solve your problem.
>
> This sort of layout is encouraged by systems that prefer separating
> architechture dependent files from architecture independent files.
> But it conflicts with the typical way Matlab's toolboxes work, which
> is that adding a toolbox only requires adding a single directory to
> the path.  So it seems this presents a compatibility problem.
>
> If you think it would be worth handling multiple .mex file extensions
> in a way that is compatible with Matlab, then I'd suggest discussing
> this on the octave-maintainers list.

ultimately, I think that since mex files are a *MATLAB* compatibility 
mechanism, it would seem logical to support their way of handling 
platform-dependent files (even though I like the Octave solution 
better). However, a quick glance at the code suggests that the ".mex" 
extension is hardcoded in a number of places, and it would probably 
take a bit of effort to change the system. Also, backward 
compatibility with existing ".mex" files would need some thought. In 
contrast, this problem is so minor and so easy to fix by adding a to 
the path that I don't think it warrants the effort. At least I don't 
feel inclined to invest effort at this time.

-M