> 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 _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
