Board index FlightGear Support Compiling

osg::GLExtensions has not been declared  Topic is solved

Building FlightGear from source, and in the need for help?

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 11:39 am

I have to agree with Thorsten.

Actually, I can even confirm that if I revert the HiDPI/QtQuick related changes to CanvasWidget.cxx and the ones introducing PUICamera.cxx (to make PUI optional during build time) , that FlightGear does again build properly using OSG 3.2.1 - note that these were all introduced at the beginning of October this year (i.e. when Dave reported them here), and these changes were announced as being a "PUI non-change, CanvasWidget appearance", given how things turned out over the course of the last 2 months, I am not sure that's a proper description to be honest - especially given that most people around here might not be able to simply revert such commits - as a matter of fact, let's keep in mind that Dave himself is a former FlightGear core developer, too, but still came here to report the problem.

https://sourceforge.net/p/flightgear/ma ... /36084254/
James wrote:Hi,

I just pushed a change which changes how we integrate PUI into the renderer and other systems; this makes our PUI usage more modular, so it can be enabled / disabled in a standard way. It also renders PUI via an FBO so we can use it safely (and scale it) on HiDPI screens, since PUI is too old to support a scaling factor as more modern UI toolkits would do.

I’ve done a fair amount of testing, and everything seems to be working, but if you see any changes in how PUI reacts to mouse or key presses, or the appearance of things, let me know. It’s using the same code as it always did but starting from a slightly different place, both in terms of drawing and event handling.

One temporary regression: right now CanvasWidget (the mechanism by which we include canvas content into PUI) is messed up because previously PUI had no alpha channel, so the canvas’s alpha was ignored. With the new system, the alpha is actually being used, but this is not really desired I think - it shows up as a semi-transparent map background in the ‘Select airport’ airfield chart, and in the Map-Canvas window at least. I thought I had a work-around for this, but the one I came up with is awkward to support on Windows, I need to think on a better solution, so in the meantime I pushed a hack so at least Windows still builds and runs.

(If your canvas content inside PUI has an opaque background, you’ll be fine, so one fix is just to adjust the Canvas code for those dialogs, but I’d like to find a backwards compatible fix)

Kind regards,
James


https://sourceforge.net/p/flightgear/ma ... /36084219/
James wrote:Steps to make PUI optional, HiDPI tolerant.

Move all PUI event and rendering into a custom camera, which can be
rendered via an FBO to account for display-resolution scaling (HiDPI).

Start wrapping PUI calls in #ifdefs so PUI can be disabled at compile
time; a run-time switch is trivial now but not implemented yet.



To be fair though, James seems to have anticipated the dilemma here:

https://sourceforge.net/p/flightgear/ma ... /35623408/
James wrote:while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby Thorsten » Sun Dec 31, 2017 11:47 am

Well, what IS the current issue with 3.2 (which runs fine for all my rendering needs and has done so for ages)?

Edit: Hooray beat me to it...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 11:52 am

well, according to the commits, the new code is using APIs to do QtQuick/HiDPI related things, probably in response to the launcher related scaling issues discussed on the devel list at the time. These were apparently raised by i4dnf and xDraconian- i.e. the launcher looking weird under some circumstances.

That is also the first time for the HiDPI acronym to be mentioned on the devel list: https://sourceforge.net/p/flightgear/ma ... h/?q=HiDPI
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby rominet » Sun Dec 31, 2017 11:56 am

James committed code to fix HiDPI scaling in some contexts. This seems to cause problems with OSG 3.2, otherwise what is this thread about? James then tried to fix these problems and found hurdles doing so, that's all I said and I don't see anything wrong with that, I even quoted him using the same words as I did.

Finally, the:
while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.

seems to be unrelated. It seems to be a fallout anticipated for the removal/replacement of PUI, which I believe is a much larger change.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 11:59 am

Wrapping PUI related calls in PUICamera.cxx and making the whole thing render via a FBO is all about making PUI optional, i.e. being able to disable it at runtime, which is even mentioned in the quoted commit message.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby Thorsten » Sun Dec 31, 2017 12:07 pm

It's a question of semantics:

Say I tinker with particles and discover that the long-standing problem that they don't interact gracefully with our effect framework can be made to go away - but only if we update to OSG 3.4 - that's what I'd call fixing a problem.

Say I tinker with adding better support for geometry shaders and make a few preliminary commits and then discover that doing this my way breaks things for everyone running OSG 3.2 - in a sense requiring 3.4 then also fixes a problem, but it fixes a problem I've just been creating myself - perhaps if I had structured things otherwise, this would not be necessary.

I won't say right or wrong, justified or not justified - but I don't see the two situations the same, and I think they shouldn't be called the same.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 12:10 pm

If the corresponding commits are not reviewed/fixed, it would probably not be a such a bad idea to change CMakeLists.txt and make sure that the new OSG 3.4 dependency is properly communicated to people building from source - from a project standpoint, it may actually not be bad to get the chance to update dependencies more aggressively (well once in a while).

EDIT: I have documented the necessary steps to revert the corresponding HiDPI commits and end up with a build environment where OSG 3.2.1 can be used again:
http://wiki.flightgear.org/Howto:Buildi ... PI_support
Image
Last edited by Hooray on Sun Dec 31, 2017 12:27 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby rominet » Sun Dec 31, 2017 12:26 pm

Hooray wrote in Sun Dec 31, 2017 11:59 am:Wrapping PUI related calls in PUICamera.cxx and making the whole thing render via a FBO is all about making PUI optional, i.e. being able to disable it at runtime, which is even mentioned in the quoted commit message.

I don't deny this is the goal (or one of the goals), but the “anticipated fallout” from https://sourceforge.net/p/flightgear/ma ... /35623408/ wasn't about this little compilation error, which will magically go away by upgrading OSG, it was about breaking many aircraft dialogs and such:
James wrote:I do not wish to cause rifts in the aircraft developer community, but it seems unlikely I can possibly replace the panels or PUI without breaking some obscure aircraft dialogs.

Thorsten wrote in Sun Dec 31, 2017 12:07 pm:Say I tinker with particles and discover that the long-standing problem that they don't interact gracefully with our effect framework can be made to go away - but only if we update to OSG 3.4 - that's what I'd call fixing a problem.

James was trying to fix a compilatin problem, AFAIK. If it's not a problem for you (or issue, his exact word), was is it then, and what are we talking about?..
Hooray wrote in Sun Dec 31, 2017 12:10 pm:If the corresponding commits are not reviewed/fixed, it would probably not be a such a bad idea to change CMakeLists.txt and make sure that the new OSG 3.4 dependency is properly communicated to people building from source - from a project standpoint, it may actually not be bad to get the chance to update dependencies more aggressively (well once in a while).

Sure, but it might be that the affair is not completly settled, as I said in my first message. James is the one handling this issue, problem, whatever you want to call it, and he is on vacation, so it seems to me that waiting for him to get back and decide on this matter might not be such a bad idea. :wink:
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 12:34 pm

As you can see above, I "solved" the problem in a way that works for me, while it is admittedly pretty crude to just revert those commits - the original consensus in the core developer community regarding any ongoing Qt5 developments was to keep everything optional, so that people not building with Qt5 support would not be affected.

And yes, in a way it is a problem if the people usually handling end-user support on the forum are affected by this (Thorsten belongs to the camp of people helping end users with such issues)

BTW: According to a number of postings here and on the devel list, Thorsten hasn't actually built FlightGear in a while, so him being directly affected or not may be irrelevant, running osgversion would tell for sure if in doubt ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby Thorsten » Sun Dec 31, 2017 12:59 pm

James was trying to fix a compilatin problem,


... which he introduced himself a little before, rather than a long standing issue or something that magically appeared - that's the whole distinction I'm after.

And I never compiled FG with Qt support, I'm fine with the commandline.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 1:03 pm

rominet wrote:this little compilation error, which will magically go away by upgrading OSG

I think Thorsten said already that James identified osgText related issues that would show up only when using 3.4 - thus, there's really not that much "magic" in this case unfortuantely ;-)

For the record, this particular problem would even show up in non-Qt builds, simply because it touches existing PUI related functionality, that was changed to suit HiDPI/QtQuick related improvements.

Imagine it like touching an ALS shader to help improve Rembrandt - you would be affected even without having to use Rembrandt.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby rominet » Sun Dec 31, 2017 3:37 pm

@Thorsten:

I think it's quite unfair to pretend James introduced a compilation problem, because I can assure you it compiles perfectly with OSG 3.4.0. It would be more correct from my POV to say that he introduced(*) a dependency on OSG 3.4 or later.

@Hooray:

AFAIK, the osgText problem is due to a bug in OSG 3.4.1 and doesn't happen with OSG 3.4.0. So, yes, the compilation problem with OSG 3.2 is very likely to magically disappear by upgrading to OSG 3.4.x. And if you avoid the "x=1" case, AFAICT you won't be affected by the a priori unrelated osgText problem. Sometimes, bugs are inadvertently introduced by updates, this is a fact, but that doesn't imply all updates are bad and none should ever be performed.

More generally, it doesn't strike me as outrageous that the bleeding edge development of FG, not even released, requires for now—might be temporary—a new version of one of its dependencies, especially one that appears to be considered as the first non-obsolete one by the OSG maintainers. I haven't seen in the FlightGear Policy Document the place that guarantees that FG will always be buildable with OSG 3.2 or lower.

We know how Thorsten dislikes upgrading FG deps, fine, but since Dany on flightgear-devel reported success running FG with the OSG 3.4 automatically built by download_and_compile.sh whereas his distro only ships older versions, it seems to me that doing the same as this script should solve the compilation problem for people who don't have OSG 3.4 in their distro. Which was already suggested on flightgear-devel, BTW.
Hooray wrote in Sun Dec 31, 2017 1:03 pm:For the record, this particular problem would even show up in non-Qt builds, simply because it touches existing PUI related functionality, that was changed to suit HiDPI/QtQuick related improvements.

Imagine it like touching an ALS shader to help improve Rembrandt - you would be affected even without having to use Rembrandt.

Well, if it's so unreasonable, I am sure James will be happy to revert his changes. :wink:

(*) Maybe temporarily, this has yet to be confirmed but again, James is on vacation as announced on flightgear-devel.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: osg::GLExtensions has not been declared

Postby Thorsten » Sun Dec 31, 2017 4:07 pm

I think it's quite unfair to pretend James introduced a compilation problem, because I can assure you it compiles perfectly with OSG 3.4.0. It would be more correct from my POV to say that he introduced(*) a dependency on OSG 3.4 or later.


Given that the official statement up to that point (even by James!) was that FG requires 3.2.0, introducing a new dependency equals introducing a compilation problem - and my whole point is that calling the making that dependency official 'fixing a problem' is more than a bit misleading and you shouldn't call it that.

If we want to bump up dependencies, fine - discuss pros and cons and make an informed decision.

More generally, it doesn't strike me as outrageous that the bleeding edge development of FG, not even released, requires for now—might be temporary—a new version of one of its dependencies,


That's explicitly not what we discuss here. Is it really so hard to see that distinction?

We know how Thorsten dislikes upgrading FG deps


I suspect you can add quite a few more less vocal people to that list below my name.

Well, I actually know that as a fact, but I won't drag others in.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: osg::GLExtensions has not been declared

Postby Hooray » Sun Dec 31, 2017 4:17 pm

I don't think this has anything to do with disliking dependency updates - Thorsten is actually among those who greatly benefit from the migration to OSG (think all the effects/shader work), and so are all of us using features that Thorsten developed, which are made possible by this very migration (AW, ALS, EarthView).
I also don't think that the change is "unreasonable" - James himself stated that he didn't expect certain issues - however, for the time being, the issue stands that people not using OSG 3.4+ cannot easily build fgfs from source, which is why it would indeed be appropriate to update the cmake config as well as all build instructions accordingly - otherwise, this is going to bite us sooner or later - especially if the people making such changes don't participate in providing the required degree of support on the forum/wiki.

Anyway, it would also not be outrageous to state clearly that we've seen a policy shift recently, i.e. an increasing tendency to deal with such build issues by simply raising version numbers of dependencies, which is potentially problematic for less tech-savvy users (and also some contributors), and which may sooner or later lower the number of people actively involved in contributing to the project.

I don't think this has anything to do with the "project policy" document you mentioned, it contains all sorts of pie-in-the-sky ideas that are nowhere close to being worked on, let alone being finished by anyone.

For now, I have documented, and shared, a "solution" for people not able to easily updgrade the corresponding dependencies (for whatever reasons).

PS: If this is about upgrading dependencies, my suggestion would be to actually have that discussion elsewhere, and provide a reasonable timeframe for people to get involved - otherwise, the frustration caused by doing so shouldn't come as a surprise. What is currently taking place in terms of "dependency management" was actually considered ridiculous and unlikely to happen a few years ago - and even Thorsten himself maintained the position, that none of this would happen without proper discussion.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: osg::GLExtensions has not been declared

Postby Thorsten » Sun Dec 31, 2017 4:23 pm

Example: If I would make a change that we link a lib in Fortran to FG, this'd compile fine for me because I have a Fortran compiler installed, but I suspect it'd break things for a lot of other people.

So, in what sense would me editing a Wiki to add the sentence 'You need g77 or f77 or an equivalent compiler to build FG' qualify as me 'fixing a compilation problem', hence we absolutely have to do it?

My guess is that most people would not feel that requiring a Fortran compiler is an adequate answer to the 'problem' - people would rightfully point out that there was no problem before I introduced it - and we'd end up discussing the wisdom of requiring a Fortran compiler (and the lib better be kickass damn good to justify all that trouble).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest