|
| From: | Simon Smith |
| Subject: | Re: [Openexr-devel] looking for a working 2.0.1 Windows build |
| Date: | Wed, 18 Jun 2014 16:09:24 +0100 |
Hi guys, These comments are thus biased to my experiences compiling OpenEXR (and OIIO/OCIO which is even trickier to get going) under Windows. I have both used CMake and hand crafted my own SLN and VCProj files, and it wasn't until I sat down and said "sod this, I'm going to get this CMake nonsense working on principle" that I fully understood things and realised that CMake does work if you go at it with the right approach I put it down to 2 things: Dependencies. Mismatches of c-runtime libraries under Windows is going to happen unless you can source all dependencies built with the same Visual Studio toolset. I think this is the biggest thing that traditional windows devs (myself included) may not quite appreciate 100% So under windows you have to either: a) Get your compiler of choice (VS2008, 2012, x64 build etc) and compile all the source you need from scratch b) Locate the dependencies that are all build from the same toolset and same linkage (i.e, static, shared libraries). Because of this you really do have to go through the pain of (a), but I really cannot stress how important this is! But this can be non-trivial as you need to know (i.e., Google!) how to configure & build all the said dependencies. Some may be CMake based, others might have a vcproj already to go, other might be nmake affairs. CMake Configuration You then have to tell CMake where to find everything - just like you would Visual Studio. This may well be a dozen paths to libs and headers, but they all need to be done. In addition, you have to tell CMake what Pre-Processor flags you want to use (normally indirectly via flags like "Static Library" etc). If you hand craft your project files rather than using CMake then you are going to have to know about all these flags anyway, so actually having CMake handle that for you through indirect flags is really rather good. The biggest hurdle here is knowing: a) What all the options are. b) CMake telling you when something is missing (like an include path or library that is needed). If these were all well documented, then it should be easier to work out how to set up CMake to spit out your project of choice. Once CMake is set up correctly, it really does work (even though it spits out loads of projects that you probably don't need or care about … or maybe you do!) So in conclusion, the system (CMake) does work, but the trick is to get the darn thing configured correctly in the first place :) For me to get from nothing to having OpenEXR, OpenImageIO, and OpenColorIO compiled took the best part of a day to do and a lot of coffee and concentration. There was no magic bullet, just a lot of hard graft :) The trouble is, even if someone did provide VS projects, you still have the issue of getting the dependencies correct anyway as the chances of finding everything you need for your choice of compiler is pretty slim indeed. NB: This does omit the issues of windows specific build issues which I believe should be fixed in the main branches. One last note on GitHub. It was mentioned that you can pull from any repositories, but when you are working on a commercial product you really want to go for the main, stable branch rather than chance "bob's branch" that might just have a bunch of tweaks that break stuff for you without you knowing it. OK, long post … sorry guys … but it's my 10p worth on a topic I can relate to :) Best Regards, On 17 Jun 2014, at 20:19, Brendan Bolles wrote:
|
| [Prev in Thread] | Current Thread | [Next in Thread] |