OpenGL page in the User Manual and OpenGL Optimizer

[duncan]

Posting here because the STR pages now seem to be read only.

I've was idly considering resurrecting a stalled OpenGL3 project on MacOSX last weekend

when I saw Manolo's post on STR 3440 "Drawing bitmap text in Fl_Gl_Window..." in

https://www.fltk.org/newsgroups.php?s16258+gfltk.bugs+v16275

Maybe I've always concentrated on the OpenGL examples in the test directory, so at

https://fltk.gitlab.io/fltk/opengl.html#opengl_with_fltk_widgets I was surprised to see

the section on OpenGL Optimizer, as this was exactly the sort of thing that I was looking

for, i.e. scene graph handling,

I was surprised by the OpenGL Optimizer link to www.sgi.com/software/optimizer but as

expected it's very old and you are redirected to somewhere in the HP general blurb pages.

A 'git blame' on the doxygen page shows that this section has not changed in 15 years!

I hunted high and low for OpenGL Optimizer but couldn't find the source code anywhere.

Basically, it looks like Open Scene Graph, OpenSG, and VSG are the only games in town.

D.

PS. Not much help out there on building OpenGL3 on MacOSX using CMake in CLion

and I'm stuck with some Xcode SDK version issue that I can't track down. Again :-(

[Manolo]

Le mardi 7 février 2023 à 08:40:00 UTC+1, duncan a écrit :

PS. Not much help out there on building OpenGL3 on MacOSX using CMake in CLion

and I'm stuck with some Xcode SDK version issue that I can't track down. Again :-(

========= reply ============

The information available at

https://fltk.gitlab.io/fltk/opengl.html#opengl3

was written in the hope it allows to build OpenGL3 apps under macOS.

[duncan]

The information available at

https://fltk.gitlab.io/fltk/opengl.html#opengl3

was written in the hope it allows to build OpenGL3 apps under macOS.

Thanks Manolo.

I used information like that from your forum posts when I set up the

project and got it working, but now I have some caching issue which

means that the build process is trying to pull in a specific version of

the SDK that does not exist on my system any more.

It's happened before when there's been an Xcode update. Not sure

if it's CLion and its builtin Cmake, or the brew cmake, or Xcode itself.

But that's an problem on my system, rather than being an FLTK issue.

D.

[Albrecht Schlosser]

On 2/7/23 13:11 duncan wrote:

... now I have some caching issue which

means that the build process is trying to pull in a specific version of

the SDK that does not exist on my system any more.

It's happened before when there's been an Xcode update. Not sure

if it's CLion and its builtin Cmake, or the brew cmake, or Xcode itself.

But that's an problem on my system, rather than being an FLTK issue.

It's a CMake issue caused by a macOS (and/or Xcode) update that replaced the SDK with another version in another folder. CMake uses the cached value and the build fails.

It happens to me from time to time as well in a bare CMake environment (not using Xcode, nor CLion). There are two possible solutions, at least for me, I don't know what you can do in your CLion build.

(1) The big hammer: just remove the entire build folder and run CMake again from scratch. This will find the new SDK, and everything is fine. Hopefully you know how to setup a new build environment from scratch (i.e. it's not grown over time ...).

(2) I'm using `cmake-gui .` (note: '.' for current/build directory) to configure with the CMake GUI, enable the "Advanced" view, then type in the "Search:" field the offending directory of the missing SDK (just "SDK" may suffice). For each displayed item, click on it, then on "X Remove Entry" to remove it. Then you can click on "Configure" and it will (hopefully) find the new SDK. This works for me. Don't worry, you can't remove too many entries, they will all be found again when you click on "Configure".

If you can't use (2) you can edit CMakeCache.txt and remove all occurrences of the SDK folder and run cmake again.

[Albrecht Schlosser]

On 2/7/23 14:26 Albrecht Schlosser wrote:

(2) I'm using `cmake-gui .` (note: '.' for current/build directory) to configure with the CMake GUI, enable the "Advanced" view, then type in the "Search:" field the offending directory of the missing SDK (just "SDK" may suffice). For each displayed item, click on it, then on "X Remove Entry" to remove it.

I just tried it again, and I noticed that you can click on the first displayed entry and then "shift click" on the last entry to select all SDK entries. I had the impression that this didn't work because the visual feedback was not optimal - but it works. Three clicks (one with shift) to remove all entries, then configure and you're done.

[duncan]

... now I have some caching issue which

means that the build process is trying to pull in a specific version of

the SDK that does not exist on my system any more.

It's happened before when there's been an Xcode update. Not sure

if it's CLion and its builtin Cmake, or the brew cmake, or Xcode itself.

But that's an problem on my system, rather than being an FLTK issue.

It's a CMake issue caused by a macOS (and/or Xcode) update that replaced the SDK with another version in another folder. CMake uses the cached value and the build fails.

It happens to me from time to time as well in a bare CMake environment (not using Xcode, nor CLion). There are two possible solutions, at least for me, I don't know what you can do in your CLion build.

Just to close this out, and add to the knowledge base...

I deleted the CMake build directory and cache files in my project. No Joy.

I deleted the CLion .idea directory and re-initialised the project. No Joy.

I deleted Xcode and re-installed it from scratch. No Joy.

I deleted my homebrew installation and reinstalled from scratch. No Joy.

I deleted my fltk-1.4.x directory, recloned, and rebuild using CMake. Success!

This is the first project where I have used the CMake build of fltk, rather

than a plain make and using 'fltk-config --ldstaticflags' to add libfltk.a to

the link command lines.

So it looks like the old SDK 11.3 path was in the fltk-1.4.x CMake cache

and not in my project's CMake cache, but I never even considered that

because explicit builds against "old" libfltk.a libraries have always worked.

Not a CLion problem. Not an Xcode update problem.

A bit of a CMake problem.

But really PEBCAK :-(

D.