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

clipka <ano### [at] anonymousorg> wrote:
> 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.

Also take into consideration that I made all the updates that were suggested by
VS at its startup and there were a couple along the past year. Even right now
there is one pending saying version 16.10.2 is now available that I was about to
click.

I just attached to this reply the requested files since I don't see
povray.beta.test.binaries in the http interface to newsgroups.

I added a couple of files that had similar names but different suffixes.

I never actually saved the files but when I made the conversion the first time
it seems to have done so and remembered the toolset, never asking me again if I
wanted to convert files made from an older version.

Don't hesitate to ask whatever else may be needed, and to my private email also
if you feel it's irrelevant to newsgroups... though most of the times such a
public searchable record can be nice for ulterior use.

Post a reply to this message

Attachments:
Download 'vs2015_but_2019_really.7z.zip' (9 KB)

clipka <ano### [at] anonymousorg> wrote:
> 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.

Hi, since then, I tried compiling for some machine that had never been exposed
to POV and got the same error message ("Cannot find Home entry in registry"):
This is to be expected when I did not do the pre requisite step of installing
any version from any previous official installer first.

However this was on purpose, as I had hoped to ultimately operate the build and
missing details of its installation process from some other package build. So
having to install a pre built package prior to build the provided sources would
not be a possible hack.


Thus my question now is... Is there any Windows geared alternative procedure
where one can build pov from some readme, AND use it, even if it has never been
installed? Is it likely that the unix prebuild.sh / make install steps are not
yet mimicked under Windows but might be with the help of the git sh tool ?
(sorry if this last point makes no sense I'm trying guesses in the dark.)

Post a reply to this message

hi,

"Mr" <nomail@nomail> wrote:
> ...
> Thus my question now is... Is there any Windows geared alternative procedure
> where one can build pov from some readme, AND use it, even if it has never been
> installed?

@Alessio Sangalli (as an alternative to running a VM):

not certain about POV-Ray working without "installing", it does need its .inc
etc files.  to answer your question - yes, I found Cygwin works well under MS
Windows, and since that gives you a fairly complete UNIX-like environment, you
can do a regular install from source.
<https://www.cygwin.com/>


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <nomail@nomail> wrote:
> > ...
> > Thus my question now is... Is there any Windows geared alternative procedure
> > where one can build pov from some readme, AND use it, even if it has never been
> > installed?
>
> @Alessio Sangalli (as an alternative to running a VM):
>
> not certain about POV-Ray working without "installing", it does need its .inc
> etc files.  to answer your question - yes, I found Cygwin works well under MS
> Windows, and since that gives you a fairly complete UNIX-like environment, you
> can do a regular install from source.
> <https://www.cygwin.com/>
>
>
> regards, jr.

My final goal is to have pov sources delivered along inside another (licence
compatible) program and have both build at the same time on Windows or Linux
without adding so many prerequestites. Using Cygwin is not an option for this,
But I don't mind how long or convoluted the launching command could get... So on
windows, after compiling in D:\pov\povray I try from command line:

D:\pov\povray>.\windows\vs2015\bin64\pvengine64-avx
+I.\distribution\scenes\advanced\grenadine.pov +L.\distribution\include
+L.\distribution\scenes\advanced\grenadine /INSTALL
D:\pov\povray\windows\vs2015\bin64 D:\pov\povray\distribution\include

And still get the same message, so the registry key seem to be really the
necessary bits are they or is it cmedit ?

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> >
> > "Mr" <nomail@nomail> wrote:
> > > ...
> > > Thus my question now is... Is there any Windows geared alternative procedure
> > > where one can build pov from some readme, AND use it, even if it has never been
> > > installed?
> >
> > @Alessio Sangalli (as an alternative to running a VM):
> >
> > not certain about POV-Ray working without "installing", it does need its .inc
> > etc files.  to answer your question - yes, I found Cygwin works well under MS
> > Windows, and since that gives you a fairly complete UNIX-like environment, you
> > can do a regular install from source.
> > <https://www.cygwin.com/>
> >
> >
> > regards, jr.
>
> My final goal is to have pov sources delivered along inside another (licence
> compatible) program and have both build at the same time on Windows or Linux
> without adding so many prerequestites. Using Cygwin is not an option for this,
> But I don't mind how long or convoluted the launching command could get... So on
> windows, after compiling in D:\pov\povray I try from command line:
>
> D:\pov\povray>.\windows\vs2015\bin64\pvengine64-avx
> +I.\distribution\scenes\advanced\grenadine.pov +L.\distribution\include
> +L.\distribution\scenes\advanced\grenadine /INSTALL
> D:\pov\povray\windows\vs2015\bin64 D:\pov\povray\distribution\include
>
> And still get the same message, so the registry key seem to be really the
> necessary bits are they or is it cmedit ?

I also tried adding the following as a *.reg file, but the result doesn't
change:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pov]
"(Default)"="POV-Ray.Scene"
"PerceivedType"="text"

[HKEY_CLASSES_ROOT\.Scene]
"(Default)"="POV-Ray scene source file"

[HKEY_CLASSES_ROOT\.Scene\DefaultIcon]
"(Default)"="D:\pov\povray\distribution\platform-specific\windows\Icons\POV-Ray.Scene-XP.ico"

[HKEY_CLASSES_ROOT\POV-Ray.Scene\shell\Render]
"(Default)"="Render with POV-Ray 3.8"

[HKEY_CLASSES_ROOT\POV-Ray.Scene\shell\Render\command]
"(Default)"="D:\pov\povray\windows\vs2015\bin64\pvengine64-avx.exe" /render "%1"

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> I also tried adding the following as a *.reg file, but the result doesn't
> change:
[...]

I was very surprised to find out here that I could move this a step further by
just adding a \help directory at the same lavel as my compiled \bin64 dir,
couldn't this be created by default ?

I had found the tip here,
https://wiki.povray.org/content/Documentation:Windows_Section_3#Non-Standard_Installations

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> "Mr" <nomail@nomail> wrote:
> > I also tried adding the following as a *.reg file, but the result doesn't
> > change:
> [...]
>
> I was very surprised to find out here that I could move this a step further by
> just adding a \help directory at the same lavel as my compiled \bin64 dir,
> couldn't this be created by default ?
>
> I had found the tip here,
>
https://wiki.povray.org/content/Documentation:Windows_Section_3#Non-Standard_Installations

Sorry, things were actually simpler than I thought, since every such
prerequisite folder already existed in the "distribution" folder, I just had to
run the built exe once with /INSTALL command line parameter followed by
distribution folder. This adds every needed registry key, and the render then
worked as smoothly as one could expect!

Post a reply to this message