Hi guys, I'm primarily a windows programmer, but we have a cross platform product (win/osx/linux) so I have to delve into linux related compilation too.
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, Simon On 17 Jun 2014, at 20:19, Brendan Bolles wrote: > On Jun 17, 2014, at 7:37 AM, Nick wrote: > >> Instead of making a Windows branch, why don't we make an EXR 2.1 branch, and >> note that one of the main features is the development of a cross platform >> Iex? > > > It seems to me like this is the whole point of writing an open source project > with git and GitHub. It's decentralized. The only difference between the > github.com/openexr/openexr repo and someone else's fork is the level of trust. > > If you want a branch with Visual Studio projects, make you own and tell other > people about it. You don't need permission from Piotr et al. If what you > make works well, people will use it and maybe someday it will get pulled back > into the original. I've got VS2008 static linking versions here if anyone > wants them: > > https://github.com/fnordware/openexr/tree/projects > > > I can't blame Piotr & co. for not wanting to deal with maintaining projects > for every build system out there. The people using those build systems > should be the ones maintaining the projects, and GitHub allows you to do just > that. > > > Brendan > > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
