Re: Making ORBit work with MS VS compilers

["Marcelo Vanzin" <mmvgroups gmail com>]

Hi Tor, thanks for the comments.

On Sat, Mar 15, 2008 at 1:15 AM, Tor Lillqvist <tml iki fi> wrote:
>  Great! That will be muchly appreciated. (I assume you are not just
>  talking about setting up VS projects, fixing inclusions of stuff like
>  unistd.h that VS doesn't have, etc here? You do know that there are
>  deeper technical reasons related to the capabilities of the object
>  file format on Windows...

Yes, I know that's not all it takes. In fact, I don't even have VS
available at home, I only have the SDK (compiler, linker, headers,
etc) and will try to make do with that, otherwise I'll have to vnc
into my work machine.

>  They are internal, I would assume, yes. (And in an ideal world they
>  wouldn't even be mentioned in the public header files, but only in
>  private headers that aren't installed by "make install".)

I'm currently testing things on Linux using GCC's visibility support
(which is not entirely the same, but helps out a bit until I set up
the Windows stuff). The problem with people calling those functions is
that they have to be exported in the library. A few of them I already
had to export due to the test code.

> Please do
>  create .def files that list only the publicly exported symbols and
>  submit also them to bugzilla.

Hmmm, that's one of the issues, .def files by themselves do not work.
They work for functions (ignoring the fact that it's a pain to keep
the .def files synced with the code, especially when you have
auto-generated code as in ORBit), but they don't work for data. For
data, you need the entry in the .def file *and* a
"__declspec(dllimport)" annotation in the header, or it won't work
with MS's linker. The fun part is that the annotation cannot be there
when compiling the DLL, only when linking to it, which requires lots
of macro-fu.

>  Hopefully the test programs included with ORBit2 should be enough to
>  test its functionality.

I'll download a few GNOME things just to make sure things work on
Linux. Not very worried about GNOME working on Windows at this point,
since this is not really my end goal. :-)

>  zenity. That stuff has obviously never been built for Win32 with
>  Microsoft's compiler before, either, just mingw, so there is some
>  porting effort involved of the trivial-ish kind, adding configure.in
>  tests for unistd.h, adding #ifdef HAVE_UNISTD_H, etc.

That's a point that I forgot to mention in my original message... do
you know of any good autoconf/automake tutorials I could read?
Everytime I look at those .in files, they look like line noise to
me...

>  In your patches, please don't use just #ifdef _MSC_VER to
>  conditionalise your changes. Use a more descriptive feature test
>  macro, like #ifdef ORBIT2_WIN32_PORTABLE_API, so that one can compile
>  with your changes also with gcc and still get code that is API and ABI
>  compatible with yours.

Noted. I will need Win32-specific code, though. (I've generally relied
on _WIN32, which is set by MS's compiler, and I see libIDL uses
G_PLATFORM_WIN32. Would one of those be OK? Are gcc for cygwin/mingw
compatible with MS's extensions like the __declspec stuff?)


-- 
Marcelo Vanzin
mmvgroups gmail com
"Life's too short to drink cheap beer."