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 ;-) 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. I think you can turn of the _MSC_VER definition with -fmsc-version= or some other flag, if you want to try that. I wouldn't recommend it, because windows.h and other system headers usually need to have _MSC_VER defined. I saw your other thread about installation troubles, but it's hard to debug remotely and I didn't have time today to respond. It sounds like you got that worked out? On Mon, Sep 29, 2014 at 8:08 PM, Eric Mader <emader at gmx.us> wrote:> 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 ;-) 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140929/116bb8ea/attachment.html>
Hi Reid, Thanks for the reply. Comments inline below. Regards, Eric On 9/29/14, 5:51 PM, Reid Kleckner wrote:> 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 think you can turn of the _MSC_VER definition with -fmsc-version= or > some other flag, if you want to try that. I wouldn't recommend it, > because windows.h and other system headers usually need to have > _MSC_VER defined.Yes, that makes sense.> I saw your other thread about installation troubles, but it's hard to > debug remotely and I didn't have time today to respond. It sounds like > you got that worked out?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.> On Mon, Sep 29, 2014 at 8:08 PM, Eric Mader <emader at gmx.us > <mailto:emader at gmx.us>> wrote: > > 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 ;-) 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140930/7aae91e0/attachment.html>