 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. I then re-targeted all
included project files.
My first attempts are to get the ancillary libraries compiling correctly.
Both the Boost libraries give errors, as do the OpenEXR libraries. The
jpeg, libpng, tiff, and zlib projects all compile (apparently) correctly.
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. However, is there any reason they aren't simply excluded
from the source, with a note that they are dependencies?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/22/2015 11:09 AM, clipka wrote:
> A quick note though: According to tradition we would probably have named
> the directory "vs14", after Visual Studio's internal version number.
IMO, whatever makes things easier.
If we get to the point where my work is being committed to the original
branch, and you ask me to rename the directory, I'll rename it. But
given that I always have to look up which version number goes with which
version of VS, I'll leave it as it is for now.
>> 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.
Given that package managers are pretty much ubiquitous in software
development (even Visual Studio has Nuget, which has served me quite
well in my {admittedly limited} needs), it may be time to rethink this.
However, my first goal is simply to get POV to compile using the new
tools, so that's a goal for another day.
> 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.
Yes, I've already noticed this from working with them yesterday.
I'll roll back to the versions included with the POV source, and just
work on getting the project files set up correctly. It may be necessary
for me to install VS2010 so I can compare, but I'll try to do it by
reading the original vcxproj files instead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2015 um 14:55 schrieb Benjamin Chambers:
> Given that package managers are pretty much ubiquitous in software
> development (even Visual Studio has Nuget, which has served me quite
> well in my {admittedly limited} needs), it may be time to rethink this.
While package managers may be /becoming/ more common right now in the
Windows world, there seem to be fundamental differences; for one, in the
Unix world package management includes distribution of libraries in
binary form, whereas NuGet seems to operate on the source code level.
As for being "ubiquitous", there's still quite a way to go; I don't know
about VS 2015, but in VS 2010 NuGet wasn't an integral part, and people
still use that version out in the wild. Also, the ready availability of
libraries still seems to be wanting, for instance according to NuGet's
web page there's no OpenEXR package yet. There's also the issue of
maintenance: Are the packages on NuGet guaranteed to be properly
maintained? By whom? In the Unix world, this is clearly the
responsibility of distro managers. Speaking of which, in the Unix world
you also have a long tradition of simply refering to your distro for
virtually all your package needs; how this will play out in the Windows
world - whether NuGet.org will advance to such a single point of
reference, or whether things will remain more spread out - is yet to be
seen.
Maintaining POV-Ray is a long-term task with limited manpower, and it's
no use exhausting ourselves by keeping up the pace with all the latest
and greatest trends in software development. We'll leave that up to
people who do shorter-term projects, see how that plays out for them,
and adopt whatever comes out as tried, tested and well-established good
practice.
No offense there; it's just the way we roll - need to roll - in POV-Ray
development.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/2015 10:13 AM, clipka wrote:
> Am 23.09.2015 um 14:55 schrieb Benjamin Chambers:
>
>> Given that package managers are pretty much ubiquitous in software
>> development (even Visual Studio has Nuget, which has served me quite
>> well in my {admittedly limited} needs), it may be time to rethink this.
>
> While package managers may be /becoming/ more common right now in the
> Windows world, there seem to be fundamental differences; for one, in the
> Unix world package management includes distribution of libraries in
> binary form, whereas NuGet seems to operate on the source code level.
I've seen both, actually. SQLite-Net, for instance, injects source
directly into your project. Most libraries seem to distribute binaries
though.
> As for being "ubiquitous", there's still quite a way to go; I don't know
> about VS 2015, but in VS 2010 NuGet wasn't an integral part, and people
> still use that version out in the wild.
Fair enough. In newer versions of Visual Studio, both package
maintenance through Nuget and source control through Github are more
tightly integrated. However, your point about VS2010 being still rather
common stands.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <56016377$1@news.povray.org>, ben### [at] outlook com
says...
>
> For anyone interested in following along,
Me! [1]
> 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
Good. It is not possible to even get a copy of vs10, so a newbie is out
of luck trying to build.
>
> I copied the directory windows/vs10 to windows/vs2015. That way, it will
> continue to compile with previous versions. I then re-targeted all
> included project files.
Don't you need povray.sln? It is missing.
>
> My first attempts are to get the ancillary libraries compiling correctly.
It looks like all you did was fix toFloat.h. I was hoping you'd be
further along. I've already hacked in the missing million boost_ptr::
in 2 non-functional workspaces.
>
> Both the Boost libraries give errors, as do the OpenEXR libraries. The
> jpeg, libpng, tiff, and zlib projects all compile (apparently) correctly.
>
> 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. However, is there any reason they aren't simply excluded
> from the source, with a note that they are dependencies?
dik
[1] I *really* want to get povdos going. I have a 4 linux box
renderfarm. My windows box is about 50% faster at povray than those 4
boxes _combined_. (All praise to whoever added SMP to povray.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FYI, I've just checked in some updates to POV-Ray to improve
compatibility with Visual Studio 2015. According to my own tests, the
official VS 2010 projects should now build flawlessly after automatic
conversion to VS 2015.
The pre-packaged version of the OpenEXR library turned out to contain an
issue that does not affect VS 2010, but causes compile errors with VS
2015. This was solved by upgrading to the latest stable version (2.2.0).
I've also changed the eLut and toFloat projects' custom build steps to
run after the Link step now, rather than the Manifest step that turned
out to cause trouble with VS 2015. The h44LogExpTable project, which
also included a post-Manifest build step, has been dropped entirely, as
the file it would generate is part of the official OpenEXR source
package anyway.
The pre-packaged version of boost also turned out to be problematic, as
it didn't provide a useful compile-time configuration for VS 2015, so
I've upgraded it to the latest stable version (1.59.0) as well. This
turned out to be incompatible with our attempts to suppress VS 2010's
C++0x features, but changing the project settings to re-enable C++0x
showed no ill effects with the current code, so that's what I've done.
There was one last boost-related issue with VS 2015, stemming from the
fact that we were using one and the same .cpp file to generate the
precompiled headers for multiple statically linked libraries (see
https://connect.microsoft.com/VisualStudio/feedback/details/1260338 for
details of this known quirk); to solve this, each library now has its
own dedicated .cpp file for precompiled header generation.
The only other thing left to do was add settings for VS 2015 to
POV-Ray's compile-time configuration.
Given how flawlessly the VS 2010 projects now seem to compile on VS 2015
after automatic conversion, I guess we'll refrain from including
official VS 2015 projects for a while longer. This way we won't have to
worry about the projects for the different versions getting out of sync,
e.g. when new source files are added.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.10.2015 um 06:58 schrieb Dick Balaska:
> [1] I *really* want to get povdos going. I have a 4 linux box
> renderfarm. My windows box is about 50% faster at povray than those 4
> boxes _combined_. (All praise to whoever added SMP to povray.)
I've just revived the "console" project, which provides a simple console
version of POV-Ray for Windows.
To build it, search the file `windows/povconfig/syspovconfig.h` for the
line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
then build the "console" project instead of the "GUI" project. This will
create a binary named "povconsole64.exe" (presuming you're building the
64-bit non-debug version).
There are a few caveats to it, for instance it doesn't automatically
read any master .ini file, nor will it be able to automatically locate
the default include files, so you'll have to specify some additional
command-line options to work around this. Also, it doesn't seem to do a
good job at guessing how many cores you have, so you may want to use the
"+wt" command-line setting to manually specify the number of threads to use.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <564526a7$1@news.povray.org>, ano### [at] anonymousorg says...
> I've just revived the "console" project, which provides a simple
> console version of POV-Ray for Windows.
Sweet!
> To build it, search the file `windows/povconfig/syspovconfig.h` for the
> line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
> then build the "console" project instead of the "GUI" project. This will
> create a binary named "povconsole64.exe" (presuming you're building the
> 64-bit non-debug version).
Er, well I'm still not building anything at the moment. :(
Can you dropbox it to me?
>
> There are a few caveats to it, for instance it doesn't automatically
> read any master .ini file, nor will it be able to automatically locate
> the default include files, so you'll have to specify some additional
> command-line options to work around this. Also, it doesn't seem to do a
> good job at guessing how many cores you have, so you may want to use the
> "+wt" command-line setting to manually specify the number of threads to use.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.11.2015 um 17:05 schrieb Dick Balaska:
> In article <564526a7$1@news.povray.org>, ano### [at] anonymousorg says...
>> I've just revived the "console" project, which provides a simple
>> console version of POV-Ray for Windows.
>
> Sweet!
>
>> To build it, search the file `windows/povconfig/syspovconfig.h` for the
>> line reading `// #define _CONSOLE`, and change it to `#define _CONSOLE`,
>> then build the "console" project instead of the "GUI" project. This will
>> create a binary named "povconsole64.exe" (presuming you're building the
>> 64-bit non-debug version).
>
> Er, well I'm still not building anything at the moment. :(
> Can you dropbox it to me?
I'm afraid I'm rather short on time these days (that, plus I don't even
have a dropbox account ;)), so maybe someone else can step in?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
