Barking Up The Wrong Tree?

I'm trying to port a bunch of code from MacOS X to Windows. The code is a mixture of C, C++11 and Objective-C. (Some of the C++ code has bits of Objective-C mixed in, just for spice :wink: Since it builds on the Mac with clang, I thought that building on Windows with clang would mean that I wouldn't have to make a bunch of changes just related to a different compiler. For example, if I do a straight port using Visual Studio, I have the replace all the uses of blocks with either callbacks or lambdas.

Having spent a couple of hours on this, I'm now wondering if perhaps it's not as straight-forward as I thought. For example, the toolset.props file adds the -fmsc-version=1800 compiler flag, which fools the conditional compilation in my header files into acting just like they do with the Visual Studio compiler. Also, I'm seeing an error where different header files have different ideas about the type of t_size, but that my just be something I have to fix.

So, bottom line. Is my assumption that using clang on Windows would simplify the porting process a valid one?

Regards,
Eric Mader

I think any port will involve some changes, but it’s really hard to say which porting approach will be the least painless beforehand. Aside from _MSC_VER incompatibilities messing up portability headers, I think any changes you make to support clang on Windows you would also have to do in order to use MSVC. MinGW is another possible compiler, but then you’re porting to gcc, which is a different amount of work.

Hi Reid,

Thanks for the reply. Comments inline below.

Regards,
Eric

One of the things I’m hoping to gain from this approach is the ability to directly compile Objective-C code. I’ll try that today and see what happens. I’m also hoping that Objective-C mixed in with C++ will work, but perhaps _MSC_VER will mean that won’t work? Yes, that makes sense. I got it worked out by copying the x86 toolset files by hand. I don’t know why the installer, or install.bat couldn’t write them - install.bat finished without any error messages.

I just tried adding a .m file to the project. Visual Studio didn't recognize it as a source file. I changed it's properties to say it was a C/C++ source file and then VS tried to compile it. I can't really tell if it was being treated as Objective-C because there are too many header file errors.

Regards,
Eric

I think any port will involve some changes, but it's really hard to say
which porting approach will be the least painless beforehand. Aside from
_MSC_VER incompatibilities messing up portability headers, I think any
changes you make to support clang on Windows you would also have to do in
order to use MSVC. MinGW is another possible compiler, but then you're
porting to gcc, which is a different amount of work.

One of the things I'm hoping to gain from this approach is the ability to
directly compile Objective-C code. I'll try that today and see what
happens. I'm also hoping that Objective-C mixed in with C++ will work, but
perhaps _MSC_VER will mean that won't work?

I don't think this will work, unfortunately. My understanding is that Obj-C
requires a fair amount of header and runtime support that won't be
available on Windows. There's no implementation of NSString, for example.

  I got it worked out by copying the x86 toolset files by hand. I don't
know why the installer, or install.bat couldn't write them - install.bat
finished without any error messages.

It would be good to run that down at some point. We've had multiple reports
of missing toolsets because our XML files didn't manage to appear in quite
the right spots.

Eric might be able to use GNUstep. The project says it supports Windows.

https://github.com/gnustep
http://www.gnu.org/software/gnustep/experience/Windows.html

Cheers,
Jevin

With my (slightly lapsed) GNUstep developer hat on:

Several commercial applications have been ported from OS X to Windows using our implementation of the Foundation and appKit frameworks and the AppKit stuff can plug into UXTheme to provide a native look for GNUstep apps on Windows.

David