POV-Ray : Newsgroups : povray.programming : qtpovray and debian Server Time
21 Sep 2021 13:46:20 EDT (-0400)
  qtpovray and debian (Message 11 to 20 of 38)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: clipka
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 14:56:32
Message: <5b2d4660$1@news.povray.org>
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

From: jr
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 15:30:01
Message: <web.5b2d4d991b94875a635cc5ad0@news.povray.org>
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

From: jr
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 18:35:00
Message: <web.5b2d77af1b94875a635cc5ad0@news.povray.org>
"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

From: dick balaska
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 18:55:57
Message: <5b2d7e7d$1@news.povray.org>
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

From: jr
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 19:55:01
Message: <web.5b2d8b031b94875a635cc5ad0@news.povray.org>
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

From: dick balaska
Subject: Re: qtpovray and debian
Date: 22 Jun 2018 21:12:46
Message: <5b2d9e8e$1@news.povray.org>
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

From: dick balaska
Subject: Re: qtpovray and debian
Date: 25 Jun 2018 04:51:20
Message: <5b30ad08$1@news.povray.org>
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

From: jr
Subject: Re: qtpovray and debian
Date: 25 Jun 2018 06:05:01
Message: <web.5b30be0e1b94875a635cc5ad0@news.povray.org>
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

From: jr
Subject: Re: qtpovray and debian
Date: 25 Jun 2018 06:15:00
Message: <web.5b30c0551b94875a635cc5ad0@news.povray.org>
"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

From: dick balaska
Subject: Re: qtpovray and debian
Date: 25 Jun 2018 16:57:31
Message: <5b31573b$1@news.povray.org>
> 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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.