Re: Mex API changes for 64bit

[David Bateman]

John W. Eaton wrote:
> On  3-Jun-2007, David Bateman wrote:
> 
> | Except this part of the change is a problem as outside of Octave
> | octave_idx_type is not defined. I see two solutions. The first is just
> | to include oct-types.h in mxarray.h, though that might not be acceptable
> | as it introduces an externally visible dependency on the octave code for
> | the mex files. The second is to move mxarray.h to mxarray.h.in and have
> | the typedefs
> | 
> | typedef  @OCTAVE_IDX_TYPE@ mwSize;
> | typedef @OCTAVE_IDX_TYPE@ mwIndex;
> | 
> | then add myarray.h.in to AC_CONFIG_FILES in configure.in. John if you
> | accept the patch for the mex API changes which of these solutions for
> | the issue of octave_idx_type do you prefer?
> 
> I think it is OK to include oct-types.h since that is just some
> typedefs and only includes standard C headers.  I don't see that it
> introduces a dependency on Octave, though it does mean you have to
> have Octave headers to compile MEX files with the Octave version of
> mex.h.  But even if it did introduce an actual dependency on Octave,
> would that be a serious problem?  The reason that Octave provides
> mex.h is to allow people to build MEX files for use with Octave, not
> so that they can build MEX files that will work with some other
> system.
> 
> jwe
> 

We also need to include config.h, which with a name like that is a
little bit more of an issue, as if we don't we end up with errors like

/opt/octave-2.9/include/octave-2.9.12+/octave/oct-types.h:43:2: error:
#error "CHAR_BIT is not 8!"

when compiling mex-files.. Do I then include config.h as well or
fallback to the other choice of a bit of autoconf magic?

D.