[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matrix.h for MEX?
From: |
Søren Hauberg |
Subject: |
Re: matrix.h for MEX? |
Date: |
Sat, 27 Mar 2010 18:19:43 -0700 |
lor, 27 03 2010 kl. 21:15 -0400, skrev John W. Eaton:
> On 27-Mar-2010, S ren Hauberg wrote:
>
> | A user just asked a question on the help-list about the MFITSIO project.
> | This provides MEX source code for reading and writing some specialised
> | image format. I tried to compile the code, but got an error saying that
> | 'matrix.h' couldn't be found. I just removed the corresponding
> | #include's and the code compiled just fine.
> |
> | I'm sure a lot of users would just have observed that the code didn't
> | compile and hence that Octave sucks. So, could we distribute a
> | 'matrix.h' header file for MEX? It could simply be an empty file as it
> | seems like we define the same stuff in 'mex.h'.
>
> And as I recall, Matlab's mex.h includes matrix.h, so you don't need
> to include matrix.h if you are also including mex.h. But apparently
> many people think both are needed.
Perhaps you needed to include 'matrix.h' many years ago and people just
never gave up the habit?
> | I see we already have a 'Matrix.h', so we can't just distribute
> | 'matrix.h' due to problems on case-insensitive file systems. So, how
> | about creating a 'mex' directory in 'include' and put 'mex.h' and
> | 'matrix.h' in there? We would then have to add this directory to the
> | include path when 'mkoctfile' is being executed with the '--mex' flag.
>
> Hmm, should we also make it so that when building mex files, the only
> include files from the Octave tree that are found by default are
> matrix.h and mex.h? After all, if you are using mex, you shouldn't
> need the other functions declared in all the other Octave headers,
> right?
I think this is the right approach. If somebody really wants to use
Octave headers in MEX files, they should be smart enough to figure out
how to do this.
Soren