Re: Making ORBit work with MS VS compilers

["Tor Lillqvist" <tml iki fi>]

> Attached is our patch for ORBit2-2.14.2, which also fixes the idl
> compiler to create code that can be built into a Windows dll.

Sorry for taking so long to get back to this issue... I haven't really
done anything about this in the meantime. I had a look at this patch
now.

The patch changes this in Makefile.shared:

-	$(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<
+	if test `uname` = "Interix" ; then \
+		$(IDL_COMPILER) $(IDL_FLAGS_W32) --deps $(*D)/.deps/$(*F).idl.P
`unixpath2win $<`; \
+	else \
+		$(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<; \
+	fi

Surely this approach can't be feasible in the long run? If the
eventual goal is for instance to make those modules in the GNOME stack
that currently can be built for Win32 with mingw on msys also
buildable with parity on Interix, aren't there hundreds of Makefiles
and other places where similar stuff would need to be changed then?
Ditto for the other parts in the diff where unixpath2win is involved.

Is it possible to use "mounts" like MSYS in Interix? I.e., is it
possible to make an Interix "Unix" path like /foo/bar refer to the
same actual location as the Win32 path X:\foo\bar? (Where X: is the
drive you are doing the work on, hopefully you don't have to use
several drive letters) Then one could simply require that such mounts
are used and no unixpath2win invocations would be needed to be added
all over the place.

I think at least currently Interix is not really that popular among
people porting software from Unix to Windows. I don't feel it would be
worth it at this point at least to apply your patch to the sources,
sorry.

--tml