 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi folks,
does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
or `v142`?
I'd be interested to hear about your experience: Whether POV-Ray does
compile - whether it runs as expected - and if not, what might prevent
it from doing so.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Hi folks,
>
> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
> or `v142`?
>
> I'd be interested to hear about your experience: Whether POV-Ray does
> compile - whether it runs as expected - and if not, what might prevent
> it from doing so.
Hello. In Visual Studio 2019, windows 10:
*Downloaded this :
https://github.com/POV-Ray/povray/archive/refs/heads/master.zip
*unzipped and opened this ...\povray-master\windows\vs2015\povray.sln with
option to auto update project toolset to v142
*Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.
*changing #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
and removing #error line 129 right below it of
.....\povray-master\source\base\build.h
*picking GUI in Windows tagrets and top menu Generate > Generate Solution
* Waited a while and properly got pvengine64d.exe inside
.....\povray-master\windows\vs2015\bin64
Output message (originally in french)ended by :
========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========
* Done a Generate > Cleanup solution and picked Release option before trying
that right now! My computer is an I7 Q720, so should I try Release-AVX or
Release-SSE2 after that ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2021 um 16:25 schrieb Mr:
>> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
>> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
>> or `v142`?
>>
>> I'd be interested to hear about your experience: Whether POV-Ray does
>> compile - whether it runs as expected - and if not, what might prevent
>> it from doing so.
> Hello. In Visual Studio 2019, windows 10:
> *Downloaded this :
> https://github.com/POV-Ray/povray/archive/refs/heads/master.zip
>
> *unzipped and opened this ...\povray-master\windows\vs2015\povray.sln with
> option to auto update project toolset to v142
>
> *Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.
>
> *changing #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
> and removing #error line 129 right below it of
> .....\povray-master\source\base\build.h
>
> *picking GUI in Windows tagrets and top menu Generate > Generate Solution
>
> * Waited a while and properly got pvengine64d.exe inside
> .....\povray-master\windows\vs2015\bin64
> Output message (originally in french)ended by :
> ========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========
>
> * Done a Generate > Cleanup solution and picked Release option before trying
> that right now! My computer is an I7 Q720, so should I try Release-AVX or
> Release-SSE2 after that ?
Thanks for helping dig into this.
To be honest, I did expect it to compile. The big question is: Do the
binaries actually do anything when you run them?
Mainly interested in the "pure" Debug and Release builds.
If they seem to work fine, please do me a favor and try again with
`#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...`
commented out in `source/base/version.h`.
I'd also be interested to learn what "auto update project toolset" does
to the project files, besides changing the toolset from `v140` to `v142`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 16:25 schrieb Mr:
>
> >> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
> >> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
> >> or `v142`?
> >>
> >> I'd be interested to hear about your experience: Whether POV-Ray does
> >> compile - whether it runs as expected - and if not, what might prevent
> >> it from doing so.
> > Hello. In Visual Studio 2019, windows 10:
> > *Downloaded this :
> > https://github.com/POV-Ray/povray/archive/refs/heads/master.zip
> >
> > *unzipped and opened this ...\povray-master\windows\vs2015\povray.sln with
> > option to auto update project toolset to v142
> >
> > *Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.
> >
> > *changing #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
> > and removing #error line 129 right below it of
> > .....\povray-master\source\base\build.h
> >
> > *picking GUI in Windows tagrets and top menu Generate > Generate Solution
> >
> > * Waited a while and properly got pvengine64d.exe inside
> > .....\povray-master\windows\vs2015\bin64
> > Output message (originally in french)ended by :
> > ========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========
> >
> > * Done a Generate > Cleanup solution and picked Release option before trying
> > that right now! My computer is an I7 Q720, so should I try Release-AVX or
> > Release-SSE2 after that ?
>
> Thanks for helping dig into this.
>
> To be honest, I did expect it to compile. The big question is: Do the
> binaries actually do anything when you run them?
>
> Mainly interested in the "pure" Debug and Release builds.
>
>
> If they seem to work fine, please do me a favor and try again with
> `#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...`
> commented out in `source/base/version.h`.
>
> I'd also be interested to learn what "auto update project toolset" does
> to the project files, besides changing the toolset from `v140` to `v142`.
Both Debug and Release do render simple scene with radiosity, point
lamp,recursive AA, mesh2 cube, 1000 sphere_sweep union, over global single
scattering media using "version 3.7" statement.
Now trying your suggested changes, assuming both at once right?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> clipka <ano### [at] anonymousorg> wrote:
> >
> > If they seem to work fine, please do me a favor and try again with
> > `#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...`
> > commented out in `source/base/version.h`.
/// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
convention or actual code? sorry, I know nothing about compiled languages yet
:-)
So I un-commented only line 114 of version.h and commented out line 128 and got
this error when running the same test scene : "Cannot Find Home entry in
registry (and cannot infer it)", screenshot attached.
Post a reply to this message
Attachments:
Download 'betaversion_without_pov_ray_host_version_criticalerror.png' (10 KB)
Preview of image 'betaversion_without_pov_ray_host_version_criticalerror.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2021 um 21:46 schrieb Mr:
> /// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
> convention or actual code? sorry, I know nothing about compiled languages yet
> :-)
To a C++ compiler, anything from `//` to the end of the line is a
comment (same deal as in POV-Ray's scene language), period. Tampering
with them will not affect the compiled program.
The `///` and `@def` are indeed comment conventions, namely of a tool
named Doxygen.
Doxygen is a tool similar to Javadoc, which can build HTML pages listing
all of the software's functions and classes and methods and stuff. By
its convention, any comment starting with `///` instead of `//` is
(generally) a documentation of whatever C++ construct follows, and
included in those HTML pages accordingly; and certain character
sequences starting with `@` have special meaning according to that
convention.
(Specifically, `@def POVRAY_IS_BETA` means that the following
Doxygen-style comment block is NOT related to the next C++ construct,
but the preorpcessor macro `POVRAY_IS_BETA` - which happens to be the
next C++ construct, but only if it isn't commented out.)
> So I un-commented only line 114 of version.h and commented out line 128 and got
> this error when running the same test scene : "Cannot Find Home entry in
> registry (and cannot infer it)", screenshot attached.
That error is to be expected in this situation when everything works
"properly".
Which leaves the question why we can't build nice working binaries on
GitHub using the v142 (VS 2019) toolset.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 21:46 schrieb Mr:
>
> > /// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
> > convention or actual code? sorry, I know nothing about compiled languages yet
> > :-)
>
> To a C++ compiler, anything from `//` to the end of the line is a
> comment (same deal as in POV-Ray's scene language), period. Tampering
> with them will not affect the compiled program.
>
> The `///` and `@def` are indeed comment conventions, namely of a tool
> named Doxygen.
>
> Doxygen is a tool similar to Javadoc, which can build HTML pages listing
> all of the software's functions and classes and methods and stuff. By
> its convention, any comment starting with `///` instead of `//` is
> (generally) a documentation of whatever C++ construct follows, and
> included in those HTML pages accordingly; and certain character
> sequences starting with `@` have special meaning according to that
> convention.
>
> (Specifically, `@def POVRAY_IS_BETA` means that the following
> Doxygen-style comment block is NOT related to the next C++ construct,
> but the preorpcessor macro `POVRAY_IS_BETA` - which happens to be the
> next C++ construct, but only if it isn't commented out.)
>
>
> > So I un-commented only line 114 of version.h and commented out line 128 and got
> > this error when running the same test scene : "Cannot Find Home entry in
> > registry (and cannot infer it)", screenshot attached.
>
> That error is to be expected in this situation when everything works
> "properly".
>
>
> Which leaves the question why we can't build nice working binaries on
> GitHub using the v142 (VS 2019) toolset.
Is it only launching the GUI solution or also the "console" and "tests" which
have unchecked boxes in my current configuration dependency list. And I haven't
tried building those setups yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Which leaves the question why we can't build nice working binaries on
> GitHub using the v142 (VS 2019) toolset.
I know nothing about it, but since not sure some stuff is not modified from your
initial settings when opening and converting toolset, let me just copy
(translate from french) some stuff that's in bold in my setup, in case it would
clue you:
Windows SDK version is 10.0
The C++ iso norm is c++14
The C version is MSVC project inherited.
MFC is set to use Standard Windows Library
Floating point model is on Precise (/fp:precise)
Activate type informations at run time (/GR) : set to yes
Whole code optimized for speed (/Ox)(/GL)(/Ot)
Security check is deactivated (/GS-)
Improved instruction set "undefined"
Startup banner removal set to yes (/nologo)
Forcing for loop scope conformity set on (/Zc:forScope)
Preprocessor definitions :
$(PovBuildDefs)BOOST_ALL_NO_LIB;NDEBUG;WIN32;WIN32_LEAN_AND_MEAN;_WINDOWS;CLASSLIB_DEFS_H;NOMINMAX;ISOLATION_AWARE_ENAB
LED;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;BUILDING_AMD64=1;COMMONCTRL_VERSION=0x500;_WIN32_WINNT=0x0501;%(Preprocessor
Definitions)
Expand inline function set to Whenever possible (/Ob2)
Function level linking deactivated (/Gy-)
Precompiled header, set to be in use (/Yu)
Precompiled header file set to winprecomp.h
Output precompiled header file set to $(IntDir)winprecomp.pch
Disable specific warnings set on with 4800;%(DisableSpecificWarnings)
Forced Include files set to winprecomp.h;%(ForcedIncludeFiles)
Warning level is 3 /WX- (do not consider warnings as errors)
Anything else you want me to check ?
I'll close and re-popen the project and try harder to spot any information at
the step when I pick platform toolset v142.
Could it be that some libraries had relative paths and then the Github system
not having the same reference point for relative paths ?
Maybe you could try submitting a totally different branch (such as HGpovray38 or
povr, to find out if the feedback is more verbose or the issue similar? )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.06.2021 um 11:55 schrieb Mr:
> Is it only launching the GUI solution or also the "console" and "tests" which
> have unchecked boxes in my current configuration dependency list. And I haven't
> tried building those setups yet.
No, "console" and "tests" are entirely different beasts; neither of
those is of any direct relevance to POV-Ray for Windows.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.06.2021 um 12:29 schrieb Mr:
> I'll close and re-popen the project and try harder to spot any information at
> the step when I pick platform toolset v142.
Could you have VS 2019 auto-convert the projects to toolset v142, save
the resulting projects, and post some of them over on
`povray.beta-test.binaries`?
`povray.vcxproj` and `povbase.vcxproj` should be helpful. Maybe also
`povray.sln`.
> Could it be that some libraries had relative paths and then the Github system
> not having the same reference point for relative paths ?
No, I don't think that's it. My money is on some project setting that
needs to be changed along with the toolset, that we don't account for.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
