Am 22.09.2015 um 16:19 schrieb Benjamin Chambers:
> For anyone interested in following along, I forked POV-Ray and created a
> new branch targeted just at getting it to compile in VS2015. The fork is
> here:
> https://github.com/BenjaminChambers/povray/tree/VS2015
> 
> I copied the directory windows/vs10 to windows/vs2015. That way, it will
> continue to compile with previous versions.

And that's the proper approach.

A quick note though: According to tradition we would probably have named
the directory "vs14", after Visual Studio's internal version number.

Then again, those internal version numbers are prone to leading to
confusion, so maybe "vs2015" isn't such a bad name after all.


> For Boost and OpenEXR, I'm going to go to the source and download new
> versions, then work to integrate them in the current directory structure
> as it is now.

It would be great if you could avoid that, and use the same versions
currently included in the POV-Ray source package.

> However, is there any reason they aren't simply excluded
> from the source, with a note that they are dependencies?

Yes, there is absolutely a reason. Two actually:

The first reason is historic. Before the advent of the World Wide Web,
and even during its early days, getting hold of 3rd party libraries used
to be quite a challenge (except on Unix systems, where package
management has a long tradition, whereas in the DOS and Windows world it
is still unheard of to this day); so to allow non-Unix users to build
their own version easily, the POV-Ray source code packages for those
systems have traditionally always come with source code for all the 3rd
party libraries POV-Ray could make use of.

The second reason is still valid today, but has the same roots, namely
that we want POV-Ray to be reasonably easy to build.

When work started on POV-Ray 3.7, the old tradition of shipping all 3rd
party libraries' source code was in fact originally not continued, most
likely primarily because the newly added boost and OpenEXR libraries
were deemed simply too large to include.

However, from our experience, building 3rd party libraries in Windows
environments per se, and more so in a manner that is compatible with the
POV-Ray build process, typically ranges from "non-trivial" to "a major
PITA", to the point that it can no longer be expected from interested
users to go through that hassle.

Case in point, the official OpenEXR build process turned out to be so
notoriously difficult to get right, that for quite a while during the
development of POV-Ray 3.7, OpenEXR support was disabled by default in
the official POV-Ray source package for Windows, and even some
developers chose to not bother trying to enable OpenEXR support in their
development builds.

Boost, too, has been difficult to build properly. It may be no
coincidence that to this date the boost thread and system libraries keep
causing trouble even in POV-Ray's Unix build process.

This was deemed unacceptable in the long run, so ultimately an endeavor
was made to set up our own set of Visual Studio projects to replicate
the OpenEXR build process; as thise projects are obviously only
guaranteed to properly work with one particular version of the
respective 3rd party library, the respective source code is now shipped
along after all - albeit only the subset required to build POV-Ray.


If this is a point you can agree with, then I would kindly ask you to
try setting up the Visual Studio 2015 build process to work with the
library versions currently provided with POV-Ray, so that your work
might be easily integrated into the official POV-Ray distribution.

If on the other hand you do not agree with this point, it would only be
logical to not replace that source code either, but instead set up the
Visual Studio 2015 build process to make use of official source packages
of the 3rd party libraries, ideally in a manner that their place of
residence doesn't collide with the existing official POV-Ray source
tree. That, too, would allow for re-integration of your work into
official POV-Ray.

Post a reply to this message