Well, after refusing to use an obsolete and messy language
like C++ at home for the last 31 years, I was curious enough
about the POV-Ray sources that I now soiled my private PC ;)

Given that a few hours ago I didn't even have a compiler,
I'm quite happy that I now have a self-compiled beta 25
pvengine32-sse2.exe, and it's barely 3am.

Some comments on the entire procedure:

o The README file was a bit unclear regarding Visual C++ Express,
   it led me to believe that I would be able to compile the beta
   using a plain Visual C++ Express, as long as I didn't want to
   build the editor DLLs. However, as pvengine.exe is a native
   Windows EXE, it absolutely requires the Platform SDK.

   Note that povcore does not require the Platform SDK, if it weren't
   statically linked to the EXE it should have been possible to keep
   the editor EXE and replace the core DLL.

o Resigned to install the platform SDK as well, I certainly didn't feel
   like swallowing the full 1GB, but opted for a custom installation and
   left out everything which I deemed unnecessary for my task, such as
   documentation, 64-bit tools and environments, IIS API and the likes.

   To anyone following me in these tracks: Obviously, it is of vital
   importance to install the "Microsoft Web Workshop Build Environment",
   which harbors the shlwapi.h for unfathomable reasons (containing
   things like GetDllVersion/DLLVERSIONINFO).

   My final platform SDK install was about 140MB.

o There may be some difference in default libraries included between
   the Professional version and the express editions. As far as I could
   see, the additional linker includes for the povwin project had only
   comctl32.lib set. I had to add "gdi32.lib user32.lib kernel32.lib
   advapi32.lib shell32.lib" as well to resolve my symbols. I suppose
   it wouldn't hurt to have these in the official project settings.

o The libname of VFE seems inconsistent with the others, i.e.
   vfewin-Release (SSE2).lib instead of vfewin-sse2.lib.

o The README contains some complaints about the odd configuration
   x64/SSE2. I think this is because SSE2 more logically denotes a
   hardware architecture than a build configuration. So, maybe it
   should just be "Release" or "Debug" configuration on the
   platforms "Win32", "Win32 SSE2" and "x64". Not sure how this
   works in detail, but it seems you can create new platforms as
   well as new configurations.

o My binary is about 800K smaller than the official one, but
   I suppose that is due to the openexr libs, whatever they do.

o Although I had already been running the beta25 on my system,
   starting my own executable prompted it to "migrate my 3.6
   settings" again.

Ok, off to bed now.

Post a reply to this message

Christian Froeschlin wrote:

>   So, maybe it should just be "Release" or "Debug" configuration on 
>   the platforms "Win32", "Win32 SSE2" and "x64".

Played with this a bit but didn't succeed in doing anything with
a new platform type after creating it in the solution configuration.
However, this might be a limitation of the Express edition.


A very minor point: The "Addition Include Directory" settings for
the povcomp project seem to be in a state where the content is the
same for all configurations, but Visual Studio thinks this is not
so (you notice the field gets blanked for "All configurations").
The problem can be fixed simply by repasting the directory
list into the field after selecting "All configurations".

Having this fixed allows to conveniently add another include path
(e.g. for the boost libraries) to all configurations simultaneously.
I know the README recommends to add boost to the list of global
includes and library path, but it is not the best style to do
this globally if a library is just used for one project.

You might also consider adding $(BOOST_ROOT) to the include
path of all projects, and $(BOOST_ROOT)\Lib to the additional
library paths for povwin. Then, the user would only need to
set the environment variable BOOST_ROOT (and if the user
prefers the old way, a bogus directory in the path
should not have any adverse effect).


I was also going to ask why the startup project is set to
jpeg instead of povwin, but it seems that information is
stored in the *.suo, which is rather braindead, really.
A workaround would be to make povwin physically the
first project in the solution (they still appear
alphabetically in solution explorer). Simply open
povray.sln in Notepad and move the 11 lines from

   Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "povwin"

up to and including

   EndProject

to the top, just before the line

   Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "jpeg"


Finally, almost silly point: The README mentions you need to
set DISTRIBUTION_MESSAGE_2 "as required" but doesn't state what
is "required". I'd suggest a comment in povray.h like:

// Please set DISTRIBUTION_MESSAGE_2 to your real name to make
// unofficial versions distinguishable from each other. Remove
// the #error directive afterwards to proceed with the build.

Post a reply to this message

Christian Froeschlin wrote:
> A very minor point: The "Addition Include Directory" settings for
> the povcomp project seem to be in a state where the content is the
> same for all configurations, but Visual Studio thinks this is not

I've fixed this (better late than never;)

> You might also consider adding $(BOOST_ROOT) to the include
> path of all projects, and $(BOOST_ROOT)\Lib to the additional
> library paths for povwin. Then, the user would only need to
> set the environment variable BOOST_ROOT (and if the user
> prefers the old way, a bogus directory in the path
> should not have any adverse effect).

I've added this as well.

-- Chris

Post a reply to this message

Chris Cason wrote:

> I've fixed this (better late than never;)

great, I had almost forgotten about this ;)

Did you also add "gdi32.lib user32.lib kernel32.lib advapi32.lib
shell32.lib" to the additional linker includes? That was probably
the only other point worth pursuing from my original mail, but
you may have missed it in the soup of tired rambling ;)

Post a reply to this message

Christian Froeschlin wrote:
> Did you also add "gdi32.lib user32.lib kernel32.lib advapi32.lib
> shell32.lib" to the additional linker includes? That was probably
> the only other point worth pursuing from my original mail, but
> you may have missed it in the soup of tired rambling ;)

ummm

[sound of furious keyboarding in the background]

why, yes, yes I did.

:]

Post a reply to this message