Re: Compiling octave with MSVC

[Michael Goffioul]

John W. Eaton a écrit :
> On 10-Oct-2006, address@hidden wrote:
>
> | I'm already using MSVC in command-line mode. However, 
> | the Makefile's generated by configure are not compatible with NMAKE,
>
> It is not so much that autoconf generates makefiles that are not
> compatible with other versions of Make as it is that Octave's
> Makefile.in files are written with GNU Make in mind.  It simplifies
> things for me to be able to assume that we can use GNU Make
> everywhere, and that seems to be a good assumption, so why not use GNU
> Make?  It seems that would be much less work than trying to rewrite
> the existing Makefiles.
>   
The problem is more about auconf, which (I guess) cannot cope with MSVC 
(object suffix,
compiler flags...). So the point would be to generate makefiles from 
existing Makefile.in's
with a MSVC-dedicated script, usable by GNU make, but using MSVC as 
compiler. I can
try if this is possible.

> | configure scripts (1h to run the complete script is normal...).
>
> Could that be related to the recent CRLF handling problem in bash that
> has been discussed on the Cygwin mailing list?  Perhaps that will not
> be such a big problem in the future.
>   
I don't know. From what I could find on the web, it seemed related to a 
very inefficient
implementation of "fork" under Win32. But it might be something else.
> | Concerning the MSVC-related
> | changes, it's mostly located in mx-*.cc files: some of them make the compiler 
> crash because
> | of the code complexity, so I made small changes to \"help\" the
> | compiler a little bit.  I'll try
> | to provide a patch in the next days.
>
> Can you extract a small portion of the changes now and show us what
> kind of changes you are talking about?  
>   
For instance, in mx-op-defs.h, I had to rewrite the NDS_CMP_OP macros as 
the following:
#define NDS_CMP_OP2(F, OP, ND, NDC, S, SC, SPEC1, SPEC2) \
 boolNDArray \
 F (const ND& m, const S& s) \
 { \
   boolNDArray r; \
\
   int len = m.length (); \
\
   r.resize (m.dims ()); \
\
   for (int i = 0; i < len; i++) \
     r.elem(i) = operator OP <SPEC1,SPEC2> (NDC (m.elem(i)), SC (s)); \
\
   return r; \
 }

If I don't use this, the compiler crashes when 's' is of type unsigned 
(uint8_t, uint16_t...).
> | Concerning the symbol export, MSVC differs from MinGW in the sense that 
> symbols are
> | not exported by default, you must explicitely export them with special 
> declaration. As I
> | splitted the code in DLL's as in the normal way (cruft.dll, octave.dll, 
> octinterp.dll), many
> | symbols from the liboctave directory must be exported. I probably exported 
> too much by
> | using some brute way, but that was to see if I could at least get somewhere.
>
> It might be useful to do have private/public symbols on all systems,
> so I'm generally in favor of making this type of change, provide that
> it doesn't cause too much of a maintenance hassle.
>   
One possible solution is to prefix exported functions with EXTERN macro 
that you can define
to "extern" under UNIX and "__declspec(dllexport/dllimport)" under 
Win32. For classes, it's
a little bit tricky as the modifier must be located after the "class" 
keyword, and you can't put
"extern" there.
> BTW, for a quick fix, is there an MSVC option to tell the compiler to
> export all symbols?
>   
Unfortunately not, otherwise I would have used it.

Michael.