Setting flags in configh.cmake.in

[Rob McDonald]

I'd like to set

HAVE_GL_GLU_H 0

[Rob McDonald]

Sorry, this sent before I was done...

On Sunday, March 17, 2024 at 12:07:20 AM UTC-7 Rob McDonald wrote:

I'd like to set

HAVE_GL_GLU_H 0

Is it possible to set this from the CMake command line the same way I set things like FLTK_BUILD_TEST and FLTK_USE_SYSTEM_ZLIB ?

When I try to pass -DHAVE_GL_GLU_H=0 to the cmake command on the command line, it does not 'take'.  Is there another way to set this?

Rob

 

[Albrecht Schlosser]

On 3/17/24 08:09 Rob McDonald wrote:

On Sunday, March 17, 2024 at 12:07:20 AM UTC-7 Rob McDonald wrote:

I'd like to set

HAVE_GL_GLU_H 0

Is it possible to set this from the CMake command line the same way I set things like FLTK_BUILD_TEST and FLTK_USE_SYSTEM_ZLIB ?

No.

When I try to pass -DHAVE_GL_GLU_H=0 to the cmake command on the command line, it does not 'take'.  Is there another way to set this?

No.

Explanation: HAVE_GL_GLU_H is an internal build variable derived from a CMake `find*` call, stored in the CMake Cache, and "exported" to 'config.h'. It is generally not possible to set such cache variables to 'false' values (e.g. 0) on the commandline or via cache variables because that triggers a new find operation in every configure execution - until it is set to a 'true' (found) value.

Please explain what you want to achieve by setting this variable in 'config.h' which is used to build FLTK but not visible in user code. It is used exclusively in 'src/gl_draw.cxx' and in two demo programs (fractals and glpuzzle). The demo programs don't work if HAVE_GL_GLU_H is 0 (they display an error message) but that's not an issue.

Is there anything wrong with 'src/gl_draw.cxx' if HAVE_GL_GLU_H==1, or what is your intention?

I need to understand what you really need. If you can give a plausible reason why we should disable 'HAVE_GL_GLU_H' although the related header file is found we might consider adding a CMake option to disable the entire search for `GL/glu.h` in our CMake code. Depending on your reasoning, how should we call such an option, maybe something like "disable glu.h" or "disable GLU"?

[Rob McDonald]

I am still working on building my program for the package-challenged RHEL9 machines.  When I build a Wayland-only build, I end up with a dependence on glvnd.  When I build in a more conventional (trying to use defaults for the whole stack), I end up with FLTK depending on GLU.

My user's machines do not have glvnd installed on them. At least some of their machines do not have GLU installed on them. Quoting from the config.h:

/*
* HAVE_GL_GLU_H:
*
* Do you have the OpenGL Utility Library header file?
* (many broken Mesa RPMs do not...)
*/

It would seem that this machine has a broken Mesa RPM installed.

Of course my development VM has tons of stuff installed, as I've been installing all kinds of packages trying to get everything bootstrapped and working.

Consequently, you can think of my situation as 'cross compiling'.  I'm on a feature-rich RHEL9 machine trying to build for a feature-deprived RHEL9 machine.  So, although CMake detects HAVE_GL_GLU_H=1 for my machine, I'd like to build with HAVE_GL_GLU=0.

As you pointed out, the only GLU call in all of FLTK itself is gluUnProject() in gl_draw.cxx.  It appears that the examples make much more extensive use of GLU.  One tempting option would be to re-implement gluUnProject natively in FLTK and remove the dependence on GLU (for the main library) entirely.  It is just a little matrix math and a permissively licensed implementation can probably be found.

The TLDR is -- I'm cross-compiling for a HAVE_GL_GLU=0 machine on a HAVE_GL_GLU=1 machine and I would like to be able to set the variable manually.

Rob