Re: [Openexr-devel] looking for a working 2.0.1 Windows build

[Nick]

For quite a while we maintained vcproj's for EXR - that works but you end up needing to keep old copies of visual studio around to make sure that it builds for 2008, 2010, 2012, ...., and then you need to run regressions on every variant to make sure nothing broke. It gets really time consuming. I think the same argument would hold for xcodeproj files.

Proposal 1 -

Something that would work would be if someone in the community hosted vcproj files, and we linked to them from the openexr md file...

Proposal 2 -

Piotr - I'd like to suggest a tiny bit of social engineering.

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?

If the branch is called Windows, then the larger EXR community might have no reason to ever try living on it. If we call it 2.1, then everyone will be incentivized to work on it, and we are much more likely to discover issues with the re-work of Iex.

- Nick

> Date: Tue, 17 Jun 2014 09:30:57 +0200
> From: address@hidden
> To: address@hidden
> Subject: Re: [Openexr-devel] looking for a working 2.0.1 Windows build
>
> On 06/17/2014 07:35 AM, Piotr Stanczyk wrote:
> >
> > I am hoping that CMake can serve our needs well.
> Somehow I disagree.
>
> I've been using and compiling free libraries using cmake for a while
> now, and I have to say that's the worst build system I've ever seen. Of
> all the libraries I've compiled, OpenEXR is the only one that I could
> build with a few tweaks only. For most of the others, it's easier and
> faster to create visual solutions from scratch than having Cmake
> correctly generating the projects.
>
> I'm quite sure that it would not be more difficult to maintain Visual
> Solution than updating the CMake config files (that's what I with other
> libraries), and far much easier for people to use them. For my point of
> view (user building third party libraries with it), Cmake seems so
> complicated, generates so many files and uses so many variables that
> it's hard to believe it's easy for library maintainers to update it.
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel