mex files for different architectures

[Xavier Delacour]

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.

Xavier

On Fri, Mar 21, 2008 at 3:04 PM, Moritz Borgmann <octave at moriborg.de> wrote:
> We are in the situation, probably not too exotic, where we run the
>  same MATLAB/Octave code on different architectures such as Solaris
>  and x86. What is the recommended practice to deal with mex files?
>  Contrary to MATLAB, Octave does not have architecture-dependent mex
>  suffixes. Do people make subdirectories for each architecture in
>  directories containing the .c files, and then add one of those
>  subdirectories to the Octave path? Before I cook up something along
>  those lines, I'd like to hear how other users do it and if there's a
>  "best practice" solution already.
>
>  The only information I could find was a post by Paul Kienzle in 2006:
>
>  http://article.gmane.org/gmane.comp.gnu.octave.maintainers/3051
>
>  >Octave deals with this by putting oct-files for different platforms
>  >in different directories.  The same mechanism will work for mex.
>
>  Thanks,
>
>  Moritz
>  _______________________________________________
>  Help-octave mailing list
>  Help-octave at octave.org
>  https://www.cae.wisc.edu/mailman/listinfo/help-octave
>