-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/12/2015 10:02 PM, Robert Osfield wrote:
Perhaps one would just need to avoid using the whole MOC stuff and
linking directly the callbacks in normal C++.
That isn't really reasonably possible without going into
undocumented/internal API
On Fri, Jun 12, 2015 at 1:00 AM, Jannik Heller scr...@baseoftrash.de wrote:
Hi Jan,
The only way you could have problems is if you rely on the OSG
libraries shipped by the distro, where you don't have control over how
it was compiled.
That is precisely what's going to happen. My
Hi Jannik,
On 12 June 2015 at 00:00, Jannik Heller scr...@baseoftrash.de wrote:
Still, I'm convinced there's a bigger issue here. I'd be curious what
Robert's thoughts are.
Issue like dependencies on 3rd party libraries that keep changing
versions/compatibility in major ways is painful for
Hi,
You just have to build OSG twice using each version of Qt in turn. OSG
respects the DESIRED_QT_VERSION already.
cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series
Yes, but then you won't be able to install those two OSG versions at the
On Fri, Jun 12, 2015 at 2:51 PM, Jannik Heller scr...@baseoftrash.de wrote:
Hi,
You just have to build OSG twice using each version of Qt in turn. OSG
respects the DESIRED_QT_VERSION already.
cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series
Hi Robert,
that's certainly an option, and it seems like the option that would place the
least burden on developers. I like the idea.
Counting the lines of code in osgQt we have just under 2000 lines in
implementation files, having that much code in headers shouldn't be too much of
a problem.
On 12 June 2015 at 20:58, Jannik Heller scr...@baseoftrash.de wrote:
On second thought, I'm not sure how this solution would interact with the
MOC (QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT,
meaning the MOC needs to run on it and produce an object file. If we move
On second thought, I'm not sure how this solution would interact with the MOC
(QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning
the MOC needs to run on it and produce an object file. If we move all code to
the headers, then it would fall on the users responsibility
Hi Jannik,
On 12 June 2015 at 18:24, Jannik Heller scr...@baseoftrash.de wrote:
as a first step to rectify the problem I have introduced a version check
within osgQt (include/osgQt/Version) to store the Qt version that osgQt has
been compiled against. If there is a version mismatch, the build
Hi,
as a first step to rectify the problem I have introduced a version check within
osgQt (include/osgQt/Version) to store the Qt version that osgQt has been
compiled against. If there is a version mismatch, the build process will abort
with an #error rather than crashing at runtime later on.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/11/2015 10:19 PM, Jannik Heller wrote:
Hi,
Recently I have had my application tested on a wide range of linux
distributions. Some users are running into a problem with Qt
version mismatch. My application gets built with Qt4, but osgQt
Hi Jan,
The only way you could have problems is if you rely on the OSG
libraries shipped by the distro, where you don't have control over how
it was compiled.
That is precisely what's going to happen. My application is likely to become
available in distro repositories (FWIW, an older
12 matches
Mail list logo
