Re: Making ORBit work with MS VS compilers

["Tor Lillqvist" <tml iki fi>]

>  I decided to take a look at how to change ORBit so it works properly
>  with the VisualStudio compilers

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 that explain why ORBit2, and code produced by
its IDL compiler currently can be compiled and linked ony with the GNU
toolchain ("mingw") for Windows, with the
--enable-runtime-pseudo-reloc flag, right?)

.> Is this the right list to send things about libIDL? I'm assuming it's
> somewhat "part" of ORBit.

I think this is a good list, yes. I am not immediately aware of any
other users of libIDL than ORBit2.

>  - How should I send patches? Should I just attach the gzipped output
>  of "svn diff", or is there a tracker for patches?

Open a bug on bugzilla.gnome.org and attach the patch((es) there.
Don't bother zipping them. Just attach diff -u output as text. If you
submit whole new files, you can combine them into a zip archive, but
don't do this for single files please.

>  - A more ORBit-specific question: there are a lot of functions in
>  several headers protected with a "ORBIT2_INTERNAL_API" define. Are
>  these *really* supposed to be internal to ORBit only (I know at least
>  a few of them are called in the test programs), or do other apps also
>  rely on these functions?

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".) Please do
create .def files that list only the publicly exported symbols and
submit also them to bugzilla. The GNU toolchain build for Win32
currently relies on just exporting all public symbols, so also the
private functions get exported from the DLLs.

>  - Are there a few recommended apps/libraries for which I should get
>  the sources so I can make sure I didn't break things with my changes?

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

If you want to test with some "real" application, I think that
unfortunately you have to go quite higher up in the GNOME stack to get
some non-"test" application. Zenity? That would mean rebuilding at
least libbonobo, GConf, libbonoboui, gnome-vfs probably, libgnome and
libbonoboui (from memory, I am probaby forgetting some libraries)
against your new ORBit2 Win32 API before you can build something like
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.

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.

And please, do follow the coding style conventions of the surrounding
code. Tab stops are at eight column intervals. (And indentation offset
is a different thing from tab stop width.) But you probably know this.

--tml