[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling octave with MSVC

From: Michael Goffioul
Subject: Re: Compiling octave with MSVC
Date: Tue, 10 Oct 2006 21:43:40 +0200
User-agent: Thunderbird (Windows/20060909)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]