I was wondering if there might be a rough, pie in the sky, timeframe for 
releasing 3.8.

There are currently 3 debian packages [1]:
povray_3.7.0.0
povray-includes_3.7.0.0
povray-examples_3.7.0.0

I will add 2 more:
qtpovray_0.1
qtpovray-extras_0.1

Should I call it 0.1?  3.8?  3.8.0.1?
qtpovray contains the executable and desktop
qtpovray-extras contains the glorious insert menu

Maybe I should call qtpovray-extras just povray-extras?

I want to leverage the existing povray-includes
which requires a release of package povray-includes_3.8.0.0
to pick up /usr/share/povray-3.8/includes .

Also, to get the .ini files especially /etc/povray/3.8/povray.conf
I need package povray_3.8.0.0 and we're not ready for that.

I could release a qmake built package povray_3.8.0.0 with the unix shell 
version (and the /etc/povray/3.8 files I need). But that's not my call 
(or true focus).  One bleh thing about that is the executable is 
/usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at 
the same time, even though the data is already separated by version.

-- 
dik
Rendered 328976 of 330000 (99%)

[1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16 
which is povray_3.7.0.0

Post a reply to this message

Am 22.06.2018 um 13:39 schrieb dick balaska:

> qtpovray_0.1
> qtpovray-extras_0.1
> 
> Should I call it 0.1?  3.8?  3.8.0.1?
> qtpovray contains the executable and desktop
> qtpovray-extras contains the glorious insert menu

I'd make sure that it is clear which version of POV-Ray it is based on.
For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
POV-Ray vX.Y.Z.

> Maybe I should call qtpovray-extras just povray-extras?

No, you should definitely not. If it's not official POV-Ray, don't make
it look like it is.

> I want to leverage the existing povray-includes
> which requires a release of package povray-includes_3.8.0.0
> to pick up /usr/share/povray-3.8/includes .
> 
> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
> I need package povray_3.8.0.0 and we're not ready for that.

In my naive understanding of Unix package management, I would suggest
for now to release qtpovray as a collection of stand-alone packages, and
later - once an official POV-Ray package is available - update it to
make use of the official POV-Ray packages, modifying part of the
qtpovray packages to do nothing more than pull in the official packages.

> I could release a qmake built package povray_3.8.0.0 with the unix shell
> version (and the /etc/povray/3.8 files I need). But that's not my call
> (or true focus).  One bleh thing about that is the executable is
> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
> the same time, even though the data is already separated by version.

I'd say that's a thing to be addressed by whoever is the maintainer of
the debian POV-Ray package. We're not doing any Unix package
maintenance, we're just providing the source code, Unix build tools, and
a bit of support. If I'm not mistaken, the configure script allows to
specify a different binary name.

If they're smart, the package also has a `/usr/bin/povray-3.7`
hard-linked to the same file (or `/usr/bin/povray` soft-linked to
`/usr/bin/povray-3.7`), so that installing another version "on top" of
it leaves an instance of the old binary available.


> [1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16
> which is povray_3.7.0.0

There's little difference there; POV-Ray v3.7.0.4 is just v3.7.0 updated
to work with the compiler and 3rd party libraries that ship with Ubuntu 18.

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> I will add 2 more [Debian pkgs]:
> qtpovray_0.1
> qtpovray-extras_0.1

fwiw, following the instructions in
http://news.povray.org/5b01fa12%241%40news.povray.org

fails to build on Slackware 14.1, a first. ;-)

jr@crow:1:povray$ make
cd qt/libpovray/ && /usr/bin/qmake /tmp/QP/povray/qt/libpovray/libpovray.pro -o
Makefile
cd qt/libpovray/ && make -f Makefile
make[1]: Entering directory `/tmp/QP/povray/qt/libpovray'
g++ -c -pipe -O2 -w -fPIC -D_REENTRANT -DQT_DEPRECATED_WARNINGS
-DOPENEXR_MISSING -DBUILD_ARCH="x86_64" -DTRY_OPTIMIZED_NOISE -DBUILD_X86
-DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++ -I.
-I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../../source
-I../../platform/unix -I../../platform/x86 -I../../unix/povconfig -I../../vfe
-I. -o tmp/QP/povray/source/backend/bounding/boundingtask.o
..../../source/backend/bounding/boundingtask.cpp
In file included from ../../source/backend/frame.h:57:0,
                 from ../../source/backend/bounding/boundingtask.cpp:42:
..../../source/base/configbase.h:1048:6: error: #error "This version of POV-Ray
requires C++11, which your compiler does not seem to support."
     #error "This version of POV-Ray requires C++11, which your compiler does
not seem to support."
      ^


I know you're only concerned with Ubuntu, but thought you'd like to know.


regards, jr.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> We're not doing any Unix package maintenance, we're just providing
> the source code,

maybe a wiki page where package scripts and/or links, and "tips + tricks", for
various platforms can be found?


regards, jr.

Post a reply to this message

On 06/22/2018 11:12 AM, jr wrote:

> requires C++11, which your compiler does not seem to support."
>       #error "This version of POV-Ray requires C++11, which your compiler does
> not seem to support."
>        ^
> 
> 
> I know you're only concerned with Ubuntu, but thought you'd like to know.
> 

I have a fix for that.  debuild (debian package maker) gave the same 
error.  Apparently, I have some personalized qt config somewhere (?) 
that throws the C++11 in there.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 06/22/2018 08:48 AM, clipka wrote:
> Am 22.06.2018 um 13:39 schrieb dick balaska:
> 
>> qtpovray_0.1
>> qtpovray-extras_0.1
>>
>> Should I call it 0.1?  3.8?  3.8.0.1?
>> qtpovray contains the executable and desktop
>> qtpovray-extras contains the glorious insert menu
> 
> I'd make sure that it is clear which version of POV-Ray it is based on.
> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
> POV-Ray vX.Y.Z.

I can do that.  So my first would be qtpovray-3.80.1
ja?

> 
>> Maybe I should call qtpovray-extras just povray-extras?
> 
> No, you should definitely not. If it's not official POV-Ray, don't make
> it look like it is.

Well, that was my first thought. But, OTOH, there is no "official" 
povray, so screw all y'all. ;)
All praise to Andreas Beckmann <anb### [at] debianorg> (who I never heard of) 
as the debian maintainer.

(
I have read so much debian foo lately. It's too much. Then I unpacked 
the debian povray port, and it's all right there, with all the right 
magic words to make 3 packages from one set of source.  The only hard 
part was was bootstrapping qmake, for which the only documentation is a 
comment in a tutorial. "How do I use qmake instead of configure?" "Since 
version blah, it just magically works".

jr whined that I didn't rename my dir root from povray to qtpovray. The 
fact that I didn't bit me in the butt here. Package qtpovray must be 
built from dir root qtpovray. Then it sees qtpovray.pro first and 
ignores any ./configure that lives there.  I'm going to have to rename 
my repo.
)

> 
>> I want to leverage the existing povray-includes
>> which requires a release of package povray-includes_3.8.0.0
>> to pick up /usr/share/povray-3.8/includes .
>>
>> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
>> I need package povray_3.8.0.0 and we're not ready for that.
> 
> In my naive understanding of Unix package management, I would suggest
> for now to release qtpovray as a collection of stand-alone packages, and
> later - once an official POV-Ray package is available - update it to
> make use of the official POV-Ray packages, modifying part of the
> qtpovray packages to do nothing more than pull in the official packages.

I will do that.
Although I would prefer if the data was in /usr/share/povray/3.[78]
I will be consistent and go with /usr/share/qtpovray-3.81 to match the 
existing style of /usr/share/povray-3.7

(Actually my personal preference is to keep it *all* together, i.e.
/opt/povray/bin
/opt/povray/etc
/opt/povray/var/include

I'm not a real fan of the debian model of sowing povray dust throughout 
the file system.  But it works for a couple hundred million (a billion?) 
installations, so it's good enough for me.
)

> 
>> I could release a qmake built package povray_3.8.0.0 with the unix shell
>> version (and the /etc/povray/3.8 files I need). But that's not my call
>> (or true focus).  One bleh thing about that is the executable is
>> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
>> the same time, even though the data is already separated by version.
> 
> I'd say that's a thing to be addressed by whoever is the maintainer of
> the debian POV-Ray package. We're not doing any Unix package
> maintenance, we're just providing the source code, Unix build tools, and
> a bit of support. If I'm not mistaken, the configure script allows to
> specify a different binary name >
> If they're smart, the package also has a `/usr/bin/povray-3.7`
> hard-linked to the same file (or `/usr/bin/povray` soft-linked to
> `/usr/bin/povray-3.7`), so that installing another version "on top" of
> it leaves an instance of the old binary available.

99% of packages don't do symlinks.  But the big boys do; gcc, python, 
wish.  I will suggest this to the debian maintainer.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > I know you're only concerned with Ubuntu, but thought you'd like to know.
> I have a fix for that.  ... some personalized qt config somewhere (?)
> that throws the C++11 in there.

I'll be happy (and a little curious :-)) to try.

btw, replying to clipka you wrote: "99% of packages don't do symlinks."

the Slackware 'makepkg' does, just like .. "the big boys".  :-)


regards, jr.

Post a reply to this message

Am 22.06.2018 um 17:15 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> We're not doing any Unix package maintenance, we're just providing
>> the source code,
> 
> maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> various platforms can be found?

If you know someone knowledgeable enough and willing to write up such a
wiki page - sure.

Post a reply to this message

Am 22.06.2018 um 17:47 schrieb dick balaska:

>> I'd make sure that it is clear which version of POV-Ray it is based on.
>> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
>> POV-Ray vX.Y.Z.
> 
> I can do that.  So my first would be qtpovray-3.80.1
> ja?

I'd go for 3.80.0, but the choice is up to you.


> jr whined that I didn't rename my dir root from povray to qtpovray. The
> fact that I didn't bit me in the butt here. Package qtpovray must be
> built from dir root qtpovray. Then it sees qtpovray.pro first and
> ignores any ./configure that lives there.  I'm going to have to rename
> my repo.

There's no rule that says your local Git repo has to have the same name
as the remote.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 22.06.2018 um 17:15 schrieb jr:
> > maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> > various platforms can be found?
>
> If you know someone knowledgeable enough and willing to write up such a
> wiki page - sure.

I'd be happy to read up sufficient on the wiki language to add the entry for
Slackware; since all packages are built from unmodified sources, it's
essentially a link to http://www.slackbuilds.org/ where one can find the package
"ingredients" for any given os release.  the scripts are maintained and use the
3.7.0.0 source.


regards, jr.

Post a reply to this message

Am 22.06.2018 um 17:12 schrieb jr:

> g++ -c -pipe -O2 -w -fPIC -D_REENTRANT -DQT_DEPRECATED_WARNINGS
> -DOPENEXR_MISSING -DBUILD_ARCH="x86_64" -DTRY_OPTIMIZED_NOISE -DBUILD_X86
> -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++ -I.
> -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../../source
> -I../../platform/unix -I../../platform/x86 -I../../unix/povconfig -I../../vfe
> -I. -o tmp/QP/povray/source/backend/bounding/boundingtask.o
> ...../../source/backend/bounding/boundingtask.cpp
> In file included from ../../source/backend/frame.h:57:0,
>                  from ../../source/backend/bounding/boundingtask.cpp:42:
> ...../../source/base/configbase.h:1048:6: error: #error "This version of POV-Ray
> requires C++11, which your compiler does not seem to support."
>      #error "This version of POV-Ray requires C++11, which your compiler does
> not seem to support."
>       ^

Presuming that you have g++ 4.8.1 or later at your disposal, you need to
smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command line. The
CPPFLAGS environment variable might do the trick.

The setting is required for all g++ versions prior to 6.1.


> I know you're only concerned with Ubuntu, but thought you'd like to know.

From what I understand, Dick is only concerned with Debian, not Ubuntu ;)

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> > g++ ...
>
> Presuming that you have g++ 4.8.1 or later at your disposal, you need to
> smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command line. The
> CPPFLAGS environment variable might do the trick.

I do, and I will try this later on.  thank you.

> The setting is required for all g++ versions prior to 6.1.
>
> > I know you're only concerned with Ubuntu, but thought you'd like to know.
>
> From what I understand, Dick is only concerned with Debian, not Ubuntu ;)

ouch, my bad.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > > g++ ...
> > ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...

spot on.  adding that option allows the process to progress until make enters
the 'qt/gui' directory, when compilation fails with missing headers (eg
QtWidgets).

I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I
remember it (building from source) being a seriously lengthy affair in 2010 or
so.  in addition, I have not even found the source archive on the qt-project.org
website yet, only link(s) to online installers.  </sigh>


regards, jr.

Post a reply to this message

On 06/22/2018 06:30 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>>> g++ ...
>>> ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...
> 
> spot on.  adding that option allows the process to progress until make enters
> the 'qt/gui' directory, when compilation fails with missing headers (eg
> QtWidgets).

The correct magic words are
CONFIG += c++11

in each of the .pro files.

> 
> I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I

I don't think qtpovray will build with Qt-4.8.

> remember it (building from source) being a seriously lengthy affair in 2010 or
> so.  

which is why I finally switched from slackware to ubuntu.  Upgrading 
apache and tomcat and php just became more tedious than I wanted.

> in addition, I have not even found the source archive on the qt-project.org
> website yet, only link(s) to online installers.  </sigh>


On 06/22/2018 12:12 PM, jr wrote:
 > btw, replying to clipka you wrote: "99% of packages don't do symlinks."
 >
 > the Slackware 'makepkg' does, just like .. "the big boys".:-)


Yes.  If you want to see symlink hell try RedHat.  Everything is 
minimally a symlink to a symlink. Everything; even the files in /etc
-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> clipka <ano### [at] anonymousorg> wrote:
> >>> ... you need to smuggle a `-std=c++11` or `-std=gnu++11` into the g++ command
line. ...
> > spot on.  adding that option allows the process to progress until make enters
> > the 'qt/gui' directory, when compilation fails with missing headers (eg
> > QtWidgets).
>
> The correct magic words are
> CONFIG += c++11
>
> in each of the .pro files.

ah, thank you for that.  qmake documentation is not installed on my machine.

> > I'll need to think whether I really want to upgrade (from 4.8.7) to 5.11, I
>
> I don't think qtpovray will build with Qt-4.8.

correct, it's missing all the frontend stuff it seems.  (unless my memory is
totally off, the library is organised substantially different from the 3.0
version I upgraded to all these years ago)

> > remember it (building from source) being a seriously lengthy affair in 2010 or
> > so.
> which is why I finally switched from slackware to ubuntu.  Upgrading
> apache and tomcat and php just became more tedious than I wanted.

yes, the java stuff always needed .. that bit extra.

if I do find the source, I likely will upgrade[*], it's just .. an unwelcome
addition on the ever-increasing todo list.

[*] I really am quite curious now to see 'qtpovray' live.

> > in addition, I have not even found the source archive on the qt-project.org
> > website yet, only link(s) to online installers.  </sigh>
> On 06/22/2018 12:12 PM, jr wrote:
>  > btw, replying to clipka you wrote: "99% of packages don't do symlinks."
>  > the Slackware 'makepkg' does, just like .. "the big boys".:-)
> Yes.  If you want to see symlink hell try RedHat.  Everything is
> minimally a symlink to a symlink. Everything; even the files in /etc

:-)  cannot be avoided though, if only for shared lib names.  'makepkg' is
reasonably smart.  it looks for existing symlinks in the compiled and built
s/ware, and generates a shell script which re-creates the links at the end of
the install.


regards, jr.

Post a reply to this message

On 06/22/2018 07:50 PM, jr wrote:
> hi,

 >> The correct magic words are
 >> CONFIG += c++11
 >>
 >> in each of the .pro files.
 >
 > ah, thank you for that.  qmake documentation is not installed on my 
machine.
 >

No loss there.  There are hundreds of magic words in qmake and the doc 
only mentions the bare basics.  Everything else is google to find out 
how someone else solved the problem.

My current quest is
      make install
or
      install {
         foo
      }
in a .pro file.  This gets 3 sentences in the doc. There is a wee bit 
more to it than that.

>>> spot on.  adding that option allows the process to progress until make enters
>>> the 'qt/gui' directory, when compilation fails with missing headers (eg
>>> QtWidgets).
>>

>>
>> I don't think qtpovray will build with Qt-4.8.
> 
> correct, it's missing all the frontend stuff it seems.  (unless my memory is
> totally off, the library is organised substantially different from the 3.0
> version I upgraded to all these years ago)
> 

You're probably not missing stuff.  Qt is all about the platform 
independent frontend.

#include <QtWidgets>
is just a shortcut instead of including the 40 or so most common objects 
individually.  I guess that is a Qt-5-ism.
(You could delete that line and then walk through the individual 
undefined object errors. ;) )

Hmm, Now I wonder if qtpovray will build with Qt-4.8.
Certainly the websockets I was using is Qt-5, but that's not in this 
edition.  I'll have to give it a try.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

I am working on two packages
qtpovray-3.80.0
qtpovray-includes-3.80.0

1) qtpovray-includes contains include  and Insert Menu. It should 
probably contain the help too.
I am torn between just the one "architecture independent" package which 
contains everything, or should I split that up into multiple packages.
Or, stay with one package and call it qtpovray-extra

2) I'm not happy with the version number (3.80.0) because I have
/usr/share/povray-3.7
and
/usr/share/qtpovray-3.80

I get it, but I don't like the way it implies qtpovray is 73 minors 
beyond povray.  Is is more, or less, confusing to have qtpovray-3.80.0 
reference /usr/share/qtpovray-3.8 ?

3) I want to release a shell version of qtpovray, comparable to original 
flavor povray, but povray 3.8-beta and built with qmake.  I need this 
for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> I am working on two packages
> qtpovray-3.80.0
> qtpovray-includes-3.80.0
>
> 1) qtpovray-includes contains include  and Insert Menu. It should
> probably contain the help too.
> I am torn between just the one "architecture independent" package which
> contains everything, or should I split that up into multiple packages.
> Or, stay with one package and call it qtpovray-extra

speaking as a potential end user, a single archive is much nicer.  :-)

> 2) I'm not happy with the version number (3.80.0) because I have
> /usr/share/povray-3.7
> and
> /usr/share/qtpovray-3.80
> I get it, but I don't like the way it implies qtpovray is 73 minors
> beyond povray.  Is is more, or less, confusing to have qtpovray-3.80.0
> reference /usr/share/qtpovray-3.8 ?

both would be "confusing" imo.  this is the first release of qtpovray, so why
not "qtpovray-1.0.0"?  I'd expect the documentation (NEWS, README, INSTALL) to
tell me "external dependencies".

> 3) I want to release a shell version of qtpovray, comparable to original
> flavor povray, but povray 3.8-beta and built with qmake.  I need this
> for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.

assuming that's a typo and you meant 'qtpovrayrc', fits in with conventions.

$0.02  :-)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> > 3) I want to release a shell version of qtpovray, comparable to original
> > flavor povray, but povray 3.8-beta and built with qmake.  I need this
> > for my renderfarm. But, what to call it?  I'm leaning towards qtpovrayc.
>
> assuming that's a typo and you meant 'qtpovrayrc', fits in with conventions.

misread what you wrote.  :-(  is there a need for two executables?  can that not
be dealt with using an option?  (some use '-interactive' to get the UI version)


regards, jr.

Post a reply to this message

> misread what you wrote.  :-(  is there a need for two executables?  can that not
> be dealt with using an option?  (some use '-interactive' to get the UI version)

It could be one executable, but that's some work.  (Two vfe/frontends, 
parse a command line, don't start the Qt loop). I can easily whip of a 
copy of the current unix povray-3.8 but built with qmake.  Plus, even if 
I don't start the gui, it's still linked to, and will load all of that 
unused Qt graphics baggage.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> It could be one executable, but that's some work.  (Two vfe/frontends,
> parse a command line, don't start the Qt loop). I can easily whip of a
> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
> I don't start the gui, it's still linked to, and will load all of that
> unused Qt graphics baggage.

out of interest, without gui, what are the differences to "stock" povray?

btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
(q)make does not pick up the QT5DIR environment variable.  when make enters the
'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
not using the qt5 include files (in four of the -I switches).


regards, jr.

Post a reply to this message

On 06/26/2018 05:45 PM, jr wrote:
> hi,
> 
> dick balaska <dic### [at] buckosoftcom> wrote:
>> It could be one executable, but that's some work.  (Two vfe/frontends,
>> parse a command line, don't start the Qt loop). I can easily whip of a
>> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
>> I don't start the gui, it's still linked to, and will load all of that
>> unused Qt graphics baggage.
> 
> out of interest, without gui, what are the differences to "stock" povray?

I should be equivalent to povray-3.8.0-alpha-something. My last merge 
was from the release/v3.8.0 branch on 2017-12-02.
povray on unix is built with autoconf/make/g++.
qtpovray on unix is built with qmake/make/g++.
If I did my job well, it will run exactly the same.

> 
> btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
> (q)make does not pick up the QT5DIR environment variable.  when make enters the
> 'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
> not using the qt5 include files (in four of the -I switches).
> 

Try
$ qmake -qt=qt5 -r
or
$ export QT_SELECT=qt5
$ qmake -r

Ref:
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu 
18.  I've thought about spinning up a Slackware 14.1 because of you. :)

> 
> regards, jr.
> 
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > out of interest, without gui, what are the differences to "stock" povray?
> I should be equivalent to povray-3.8.0-alpha-something. ...

ok.

> > btw, installed Qt5 but hit another snag with the qtpovray build.  ...
> Try
> $ qmake -qt=qt5 -r
> or
> $ export QT_SELECT=qt5
> $ qmake -r
> Ref:
>
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

that link helped, the '--version' providing the clue.  /usr/bin/qmake is a
symbolic link.  :-) installation of Qt5 left the existing link alone, easily
remedied.  and leading to another problem.  sorry.

Script started on Wed 27 Jun 2018 11:33:46 BST
jr@crow:13:qtpovray$ make
cd qt/libpovray/ && ( test -e Makefile || /usr/bin/qmake
/tmp/B/qtpovray/qt/libpovray/libpovray.pro -o Makefile ) && make -f Makefile
make[1]: Entering directory `/tmp/B/qtpovray/qt/libpovray'

runs ok until:

g++ -c -pipe -O2 -march=native -mtune=native -fPIC -std=gnu++11 -Wall -W
-D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_WIDGETS_LIB
-DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../vfe -I../vfe -I../libpovray -I../platform
-isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem
/usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I.
-I/usr/lib64/qt5/mkspecs/linux-g++ -o codeeditor.o editor/codeeditor.cpp
editor/codeeditor.cpp: In member function ‘void
CodeEditor::configure(PreferenceData*)’:
editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member named
‘setTabStopDistance’
  this->setTabStopDistance(fm.width(spaces));
        ^
make[1]: *** [codeeditor.o] Error 1
make[1]: Leaving directory `/tmp/B/qtpovray/qt/gui'
make: *** [sub-qt-gui-make_first-ordered] Error 2
jr@crow:14:qtpovray$

the library version is 5.7.1.


> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)

:-)  maybe that's a subconscious .. yearning for the old days.  ;-)

if you do make it 14.2 though, which most use.  apparently, 15.0 is a
possibility for later this year.


regards, jr.

Post a reply to this message

On 06/27/2018 01:00 PM, jr wrote:
> hi,

> editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member named
> ‘setTabStopDistance’
>    this->setTabStopDistance(fm.width(spaces));
>          ^

Sorry about that. I actually fixed that (debian defaults to an older 
"official" version of Qt) but I didn't push the changes back to github.
https://github.com/dickbalaska/qtpovray/commit/d70eede7700cbde40cbdbd6347a4a50ef85763a2

Try it now.

Also note the repo changed names.

git clone https://github.com/dickbalaska/qtpovray.git
cd qtpovray
git checkout qtpovray
qmake
make -j4
qt/gui/qtpovray        # run the executable


 >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
 >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
 >
 > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)

Yeah, I miss working for hours to get an integrated apache/php/ssl chain
(or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.
I stuck with slackware for so long because, loyalty, and because I 
wanted to be more intimate with those tools.  These days, I just want it 
to work. :)

 >
 > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
 > possibility for later this year.
 >

I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or 
5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member > Sorry
about that. I actually fixed that 
(debian defaults to an older
> "official" version of Qt) but I didn't push the changes back to github.
> Try it now.
> Also note the repo changed names.
>
> git clone https://github.com/dickbalaska/qtpovray.git
> cd qtpovray
> git checkout qtpovray
> qmake
> make -j4

thank you, both for the whole thing + the renaming.
now works as expected.

> qt/gui/qtpovray        # run the executable

ah, yes.  another problem, afraid to say..

start 'qtpovray', open a scene file, looks ok in editor, click the green arrow,
and:

  chdir:  /home/jr/wip/pov/media
  command:

appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
log:

[12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
file provided" ((null):0)
[12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)

no other, discernable activity.  [raised eyebrow emoji, if I knew it]

from the 'qtpov.ini':

[General]
recentWorkspaces=/home/jr/.cache/qtpovray/b.pws

[EditorColors]

[Keys]

[Preferences]
PovrayExecutable=/usr/local/bin/povray380a
PovrayIncludes=/usr/local/share/povray-3.8/include
PovrayInsertMenu=


no idea what a "PovrayInsertMenu" is, is it needed?

>  >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
>  >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
>  >
>  > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)
>
> Yeah, I miss working for hours to get an integrated apache/php/ssl chain
> (or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.

</grin>

> I stuck with slackware for so long because, loyalty, and because I
> wanted to be more intimate with those tools.  These days, I just want it
> to work. :)
>  > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
>  > possibility for later this year.
> I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or
> 5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

ok.  I'll be happy to test building here should you decide to go for it


regards, jr.

Post a reply to this message

On 06/28/2018 12:39 PM, jr wrote:
> hi,

> 
>> qt/gui/qtpovray        # run the executable
> 
> ah, yes.  another problem, afraid to say..
> 
> start 'qtpovray',

Well that's progress!

> open a scene file, looks ok in editor, click the green arrow,
> and:
> 
>    chdir:  /home/jr/wip/pov/media
>    command:
> 
> appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
> log:
> 
> [12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
> file provided" ((null):0)
> [12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)
> 
> no other, discernable activity.  [raised eyebrow emoji, if I knew it]
> 

Although you may be looking at the file in the editor, you haven't 
selected it for rendering. (No input file provided).
Try right-click on the filename in the Resources view and "Select for 
Render"

Weird my tutorial fails to mention this step.
http://www.buckosoft.com/qtpovray/tutorial/

I am concerned in your report that the "No input file provided" message 
did not appear in the Consoles.POV-Ray box. That's a bug.

> from the 'qtpov.ini':
> 
> [General]
> recentWorkspaces=/home/jr/.cache/qtpovray/b.pws
> 
> [EditorColors]
> 
> [Keys]
> 
> [Preferences]
> PovrayExecutable=/usr/local/bin/povray380a
> PovrayIncludes=/usr/local/share/povray-3.8/include
> PovrayInsertMenu=
> 
> 
> no idea what a "PovrayInsertMenu" is, is it needed?

Not needed, but a cool feature. It is adopted from the POV-Ray for 
Windows insert menu. Basically it is a pile of code snippets with 
preview graphics that you can insert into your SDL.
http://www.buckosoft.com/qtpovray/insertText/

 > PovrayExecutable=/usr/local/bin/povray380a

This line is dead. It is left over from the websockets edition and is 
unused.



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> Although you may be looking at the file in the editor, you haven't
> selected it for rendering. (No input file provided).
> Try right-click on the filename in the Resources view and "Select for
> Render"

will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
executables named 'povrayNN*', a symlink would be not as convenient for my
setup, the ("dead") .ini file option looks so much better.  would it be much
work to "resurrect" it?

> Weird my tutorial fails to mention this step.
> http://www.buckosoft.com/qtpovray/tutorial/
>
> I am concerned in your report that the "No input file provided" message
> did not appear in the Consoles.POV-Ray box. That's a bug.

</weak-sounding-hurrah>  :-)

> > no idea what a "PovrayInsertMenu" is, is it needed?
> Not needed, but a cool feature. It is adopted from the POV-Ray for
> Windows insert menu. Basically it is a pile of code snippets with
> preview graphics that you can insert into your SDL.
> http://www.buckosoft.com/qtpovray/insertText/

I'll look into this.  thanks.

>  > PovrayExecutable=/usr/local/bin/povray380a
> This line is dead. It is left over from the websockets edition and is
> unused.


regards ,jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> > Try right-click on the filename in the Resources view and "Select for
> > Render"
> will do.

success.  :-)

btw, is there a legit way to 'wget' the documentation part of your website?
convenience..

cheers.


regards, jr.

Post a reply to this message

hi,

how does one re-open the render view + Consoles widgets after they have been
closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

happened because I rendered a static scene, clicked that editor tab shut, opened
another scene, then the associated ini, chose that for rendering.  however, the
view of the previous image remained, so I clicked it shut - only not to find a
way to reopen it.

btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
and I get:

xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
per invocation.

[19:23:28.805] WARN
Unhandled PrintStatusChanged
 ((null):0)

[19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

would like to read the tutorial etc, but, probably because I'm a bit dense at
times, the "compass" feature does not work for me, which "next" button?


regards, jr.

Post a reply to this message

On 06/28/2018 03:08 PM, jr wrote:
> hi,
> 
> how does one re-open the render view + Consoles widgets after they have been
> closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

I think I can add the 'view' menu.  Currently, it is Qt magic. 
Right-click on one of the docking borders. That is, the "Resources" 
header or the "Consoles" header. It will give you a list of available 
windows to turn on and off.

> 
> btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> and I get:
> 
> xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
> xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

If you didn't install them, that's pretty much what you get.  I am going 
to dim those menu entries if they don't exist. And add a bit in the 
config dialog so you can point to wherever those directories live on 
your system.  I just added those two menus last night, having discovered 
the pretty awesome distribution/scenes directory (open that in firefox).

> 
> also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> per invocation.
> 
> [19:23:28.805] WARN
> Unhandled PrintStatusChanged
>   ((null):0)

This is debug foo. I should remove it from production.  Basically povray 
is telling me something I'm ignoring.

> 
> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

This one is interesting.  Um, what it means is um ...
I would guess maybe it's trying to draw to one of the windows you closed 
(although Qt should be filtering that).

> 
> would like to read the tutorial etc, but, probably because I'm a bit dense at
> times, the "compass" feature does not work for me, which "next" button?

Last night I copied
http://www.buckosoft.com/qtpov/
to
http://www.buckosoft.com/qtpovray/

and didn't fix the database driven navigation.  (I needed the url for 
the debian package.) Use the first one and ignore the bits about a 
separate websockets executable, and everywhere else read "qtpovray" 
where it says "qtpov".
I am going to rework that so it can be included with the package.

> 
> 
> regards, jr.

Thanks for trying it out!



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 06/28/2018 01:54 PM, jr wrote:
> hi,

> 
> will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
> executables named 'povrayNN*', a symlink would be not as convenient for my
> setup, the ("dead") .ini file option looks so much better.  would it be much
> work to "resurrect" it?

povray is built into qtpovray.  There is no need for a separate 
executable.  A symlink would be of no value because there is nothing to 
point to. ;)



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > how does one re-open the render view + Consoles widgets after they have been
> > closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.
>
> I think I can add the 'view' menu.  Currently, it is Qt magic.
> Right-click on one of the docking borders. That is, the "Resources"
> header or the "Consoles" header. It will give you a list of available
> windows to turn on and off.

I tried switching all except 'main' off, then there seems to be no "docking
border"s.

> > btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> If you didn't install them, that's pretty much what you get.  I am going
> to dim those menu entries if they don't exist.

yes, or (as many do) a simple "ok" type dialog with message?

> And add a bit in the
> config dialog so you can point to wherever those directories live on
> your system.

sounds good.  more flexibility.

>  I just added those two menus last night, having discovered
> the pretty awesome distribution/scenes directory (open that in firefox).

I have those too, did them for povray 3.7.

> > also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> > per invocation.
> >
> > [19:23:28.805] WARN
> > Unhandled PrintStatusChanged
> >   ((null):0)
>
> This is debug foo. I should remove it from production.  Basically povray
> is telling me something I'm ignoring.

ok.

> > [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> > resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>
> This one is interesting.  Um, what it means is um ...
> I would guess maybe it's trying to draw to one of the windows you closed
> (although Qt should be filtering that).

I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
existing .pws files).

> > would like to read the tutorial etc, but, probably because I'm a bit dense at
> > times, the "compass" feature does not work for me, which "next" button?
> Last night I copied
> http://www.buckosoft.com/qtpov/
> to
> http://www.buckosoft.com/qtpovray/
> and didn't fix the database driven navigation.  (I needed the url for
> the debian package.) Use the first one and ignore the bits about a
> separate websockets executable, and everywhere else read "qtpovray"
> where it says "qtpov".
> I am going to rework that so it can be included with the package.

cool.

> Thanks for trying it out!

soon you'll be pulling your hair out because I'll be nitpicking and flood you
with "feature requests".  :-)

speaking of which, the name of the current workspace (file) would be good to
have in the titlebar, or somewhere prominent.

(see, it's already started..  :-))


regards, jr.

Post a reply to this message

On 06/28/2018 05:50 PM, jr wrote:
> hi,

>>
>> I think I can add the 'view' menu.  Currently, it is Qt magic.
>> Right-click on one of the docking borders. That is, the "Resources"
>> header or the "Consoles" header. It will give you a list of available
>> windows to turn on and off.
> 
> I tried switching all except 'main' off, then there seems to be no "docking
> border"s.
> 

Hmm, yes I see. You're kind of screwed, eh?

The toolbar has a grabber on the left side. Try to right-click that, or 
someplace on the toolbar that's not a button.


> 
>>> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
>>> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>>
>> This one is interesting.  Um, what it means is um ...
>> I would guess maybe it's trying to draw to one of the windows you closed
>> (although Qt should be filtering that).
> 
> I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> existing .pws files).

Since this is something between Qt and X11, it would be helpful to know 
when this error^H^H warning occurred.  My X log just has a ton of 
"monitor on, monitor off".


> 
> soon you'll be pulling your hair out because I'll be nitpicking and flood you
> with "feature requests".  :-)
> 
> speaking of which, the name of the current workspace (file) would be good to
> have in the titlebar, or somewhere prominent.
> 
> (see, it's already started..  :-))

I guess I should open the github bug thingy.

> 
> 
> regards, jr.
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> I think I can add the 'view' menu.  Currently, it is Qt magic.
> > I tried switching all except 'main' off, then there seems to be no "docking
> > border"s.
> Hmm, yes I see. You're kind of screwed, eh?

didn't you mean "screwy"?  :-)

> The toolbar has a grabber on the left side. Try to right-click that, or
> someplace on the toolbar that's not a button.

either way, thanks, easy -- once one knows.

> >>> [19:51:01.141] WARN QXcbConnection: XCB error: ...
> >> This one is interesting.  Um, what it means is um ...
> >> I would guess maybe it's trying to draw to one of the windows you closed
> >> (although Qt should be filtering that).
> > I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> > existing .pws files).
> Since this is something between Qt and X11, it would be helpful to know
> when this error^H^H warning occurred.  My X log just has a ton of
> "monitor on, monitor off".

I understand.  will try and pay closer attention when I'll use/play with
'qtpovray'.

> > soon you'll be pulling your hair out because I'll be nitpicking and flood you
> > with "feature requests".  :-)
> >
> > speaking of which, the name of the current workspace (file) would be good to
> > have in the titlebar, or somewhere prominent.
> >
> > (see, it's already started..  :-))
>
> I guess I should open the github bug thingy.

I'll make it worth your while: whether checked or not, "large icons" is,
apparently, all that is on offer.  ;-)


regards, jr.

Post a reply to this message

I don't get git.
My last merge of povray was from master on 12/17/17.
At the time, source/base/version.h was reporting povray as version
3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"

I picked up that version number (and didn't really care).

In my head, I noticed a discrepancy when clipka suggested I call mine
v3.80.0 (why not 3.81.0 ?).

Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
most of the branches.

I just merged autobuild/alpha_v380.  In source/base/version.h I picked
up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
from 2017 to 2018.
But, I still have
#define POV_RAY_PATCHLEVEL_INT      1
instead of
#define POV_RAY_PATCHLEVEL_INT      0
which is in the merged-from file.

Why?  I have not altered this, and if I had, I should get a conflict.
If makes me nervous for whatever other files I may not have picked up
changes on.

https://github.com/dickbalaska/qtpovray/commit/f0eb4228ecfe624e905fe04367a73d3cc514f8fa#diff-456b041bdd8c9f06ec0514302ebba61b
( https://tinyurl.com/y7t5hh8x )
-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

For the records, that was not a burp. Here's what had happened:

- What is now v3.8.0 (currently in alpha phase) was originally slated to
be released as v3.7.1, and as such had already reached beta phase (and,
for a few days, even RC phase) before being rebranded as v3.8.0.

- Upon reaching beta phase, v3.7.1 was branched off `master` so that
finalization of that version could happen in a separate branch
(`release/v3.7.1`), while the master branch could continue to be used
for adding new features. At that point, the master branch was bumped to
version number v3.7.2-alpha.

- When it was decided that v3.7.1 would be too different from v3.7.0, it
was re-branded v3.8.0.

- While v3.8.0 was put back into alpha stage, it was originally expected
that the version would quickly fast-forward to RC phase again. It was
therefore left in its own branch (though now renamed `release/v3.8.0`),
while the master branch was bumped to the next version number, v3.8.1.

- When it became obvious that v3.8.0-beta wasn't going to be just a few
days ahead, all the changes in the master branch (i.e. changes
originally slated for a later version) were also merged into v3.8.0, and
that version moved back into the master branch. (Technically this was
done by simply merging v3.8.0 into the master branch.)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

"Most" is the keyword here.

> I just merged autobuild/alpha_v380.  In source/base/version.h I picked
> up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
> from 2017 to 2018.
> But, I still have
> #define POV_RAY_PATCHLEVEL_INT      1
> instead of
> #define POV_RAY_PATCHLEVEL_INT      0
> which is in the merged-from file.
> 
> Why?  I have not altered this, and if I had, I should get a conflict.
> If makes me nervous for whatever other files I may not have picked up
> changes on.

Unfortunately, v3.8.0-alpha.9606898 was built just /before/ the merge of
`master` and `release/v3.8.0`.

This means your version number details are determined as follows:

- The _common base_ is the last common ancestor (including merges) of
`qtpovray` and `autobuild/alpha_v380`. That would be commit bb85b4fd
dated 2017-11-18, then on the `release/v3.8.0` branch. On that commit,
the version number details were as follows:

    #define POV_RAY_MAJOR_VERSION_INT   3
    #define POV_RAY_MINOR_VERSION_INT   8
    #define POV_RAY_REVISION_INT        0
    #define POV_RAY_PATCHLEVEL_INT      0
    #define POV_RAY_PRERELEASE          "alpha"

- One line of inheritance would be via the `master` branch and then
`qtpovray`, starting with the merge commit b3038c26 dated 2017-12-03.
While this commit leaves the version number unchanged /on the master
branch/, the commit /does/ constitute a version number change with
respect to the _common base_, changing the following:

    #define POV_RAY_REVISION_INT        1

- The second line of inheritance would be via `release/v3.8.0` and then
`autobuild/alpha_v380`. The only version number changes with respect to
the _common base_ in this line of inheritance are changes of the
prerelease ID, with the last such change being the following:

    #define POV_RAY_PRERELEASE          "alpha.9606898"

So you have one line of inheritance saying POV_RAY_REVISION_INT needs to
be changed to 1, and another line of inheritance saying
POV_RAY_PRERELEASE needs to be changed from "alpha" to "alpha.9606898".

Since the changes seem to be independent, no conflict is raised, leaving
you with version number v3.8.1-alpha.9606898.

Post a reply to this message

On 07/16/2018 08:57 AM, clipka wrote:

> while the master branch was bumped to the next version number, v3.8.1.

That makes sense.  I retract 'burp'.

(I had assumed [1] you changed 3.7.1 to 3.8.0 and changed the 7 to 8 and
forgot to change 1 to 0.)


[1] When you assume ...

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message