> On 10-Oct-2006, address@hidden wrote:
> | For my personal usage, I ported octave to MSVC compiler (version 14,
> | aka VS2005), which is freely available.
>
> I suppose it depends on your definition of "free". Although it may beavailable free of
> charge, it is not exactly free (as in speech)software.In any case, can you say why you
> needed this, other than for thechallenge of doing it?
I don't want to enter the debate about whether using MSVC is a good idea or not.
The fact is that MSVC is the only compiler providing access to all Win32 technologies.
The fact that it is now available free of charge is nice; I guess you didn't expect it to be
released under GPL ;-)
>
> | Most of the work involved providing a build framework
> | (Makefile's and config.h)
>
> Since these files change often, I would really like to avoid having aseparate set of
> Makefiles for a single compiler that must bemaintained in parallel with the files generated
> from the .in files, sowe must find a way to generate the files automatically. Isn't itpossible
> to run the MSVC compiler in a command-line mode that willwork with the configure
> script, possibly using the MSYS or Cygwinshell?
I'm already using MSVC in command-line mode. However,
the Makefile's generated by configure are not compatible with NMAKE, moreover I don't
know if MSVC can be made compatible with the configure scripts. The fact is that I wanted
to get rid of the use of a shell, especially the cygwin one, which is awfully slow when running
configure scripts (1h to run the complete script is normal...). The easiest and fastest solution
is to provide MSVC-dedicated Makefile's. From my experience with another UNIX-ish
project I ported, once you have a set of Makefile's, they don't change that much afterwards
and maintining them is straightforward.
> | and exporting the required functions (+
> | some small changes to cope with MSVC). Is there any interest in
> | such port? If yes, I could try to provide a decent patch (quite
> | huge, due to the many required __declspec(dllexport) declarations),
> | otherwise, I'll keep this locally.
>
> Yes, I would be interested in seeing what is needed.Would you be willing to first separate
> out the small changes to copewith MSVC so we can evaluate those separately, then
> explain whichsymbols need to be exported?
I currently trying to port my work to current CVS, avoiding static files as much as possible
(by using sed, perl and awk as in the normal build process). 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.
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.
> How did you mark the symbols for export? I
> think I'd prefer to hidethe details in a macro.