RE: MSVC compiler support [patch 17]: octinterp.dll exported symbols

[michael . goffioul]

> Is it OK to do the use OCTAVE_EXPORT, and define that appropriately in
> config.h?  Currently, OCTAVE_EXPORT is defined to be empty unless
> _MSC_VER is defined, but that might change in the future.

OK.
 
> This seems to be needed because HAVE_ATEXIT is not defined.  Is atexit
> really not available, or is there some problem with it?  If there was
> a problem, I'd like to try to find a solution because we need to have
> some kind of atexit functionality.

atexit() is available under MSVC. I don't remember why I did it (probably
while trying something), but from a code point-of-view, such an include
would be necessary if HAVE_ATEXIT is not defined. From a MSVC point
of view, you can leave out this change.
 
> + #ifdef _MSC_VER
> + #ifndef OCTINTERP_API
> + #define OCTINTERP_API __declspec(dllimport)
> + #endif
> + #endif
> +   
>  #include "mexproto.h"
>  
>   /* V4 floating point routines renamed in V5.  */
>
> I'm not sure I understand why this is defined here instead of in
> mexproto.h since no symbols in mex.h are tagged with OCTINTERP_API,
> but many symbols in mexproto.h are.  It would be better to have this
> declared in config.h or some other header that is included in
> mexproto.h.  Perhaps we need to have a header template like this

Yes, it would be better located in mexproto.h. The problem I had, while
porting a MEX file I had, was that when you simply include mex.h, config.h
is not included and OCTINTERP_API is not defined, leading to problems
at link time. So I added this manual OCTINTERP_API definition. But
maybe the idea is that the user is required to include config.h instead.
 
Michael.