View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013306CMakeModulespublic2012-06-14 16:452016-06-10 14:31
ReporterJona 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSWindowsOS Version7
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013306: findglut bug
DescriptionI have installed freeglut on my system, but FindGlut.cmake is unable to find it. I have an enviroment variable called GLUT_ROOT_PATH but it is not used by the skript.

I rewrote the script and now it works for me:

IF (WIN32)
  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h
    PATHS ENV GLUT_ROOT_PATH
    PATH_SUFFIXES include
    )
  FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
    PATHS ENV OPENGL_LIBRARY_DIR GLUT_ROOT_PATH
    PATH_SUFFIXES Release lib
    )
ELSE (WIN32)

The old version was:
IF (WIN32)
  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h
    PATHS ${GLUT_ROOT_PATH}/include )
  FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
    PATHS
    ${OPENGL_LIBRARY_DIR}
    ${GLUT_ROOT_PATH}/Release
    )
ELSE (WIN32)

(as I can see, it uses the cmake variable GLUT_ROOT_PATH instead of the enviromentvariable and doenst look inside /lib for the library.

TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0030440)
David Cole (manager)
2012-08-11 21:42

Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0030925)
Brandon Van Every (reporter)
2012-09-05 09:25

Are these date stamps accurate? They seem to say, a bug + a possible fix was submitted on June 14, 2012. Put into the backlog on August 11, 2012. That's less than 2 months. In terms of volunteer open source labor, what people have the time to track down and submit, that's a rather fresh bug. Calling such a bug "old" doesn't send a good message. Please consider changing your threshold of what you call "old" to something more reasonable. 6..12 months? Or else don't call it "old," just call it "never assigned."
(0030928)
David Cole (manager)
2012-09-05 14:31

The date stamps are accurate.

I agree that perhaps my judgment call of using "2 months" as an "old" threshold was on the small side. Maybe 6 is more reasonable. 12... I don't know. Just as calling it "old" doesn't send a good message, neither does leaving it as "new" and "unassigned" for a year. If nobody's going to be doing anything about it, shouldn't it be categorized and clearly labelled as such?

On the other hand, if nobody's doing anything about it, then sending it to the "backlog" notifies the person who submitted the bug that an action has been taken. If that person wants, he may respond by saying "hey, no fair, this is important."

The goal with this action was to trigger such reactions from people who care about the issues enough to speak up further about the individual ones that are important.

Nobody likes to wade through masses of bugs, trying to prioritize them. Doing this is a way of getting the important ones back on the roadmap.

If you object to specific bugs having been sent to the backlog, please do let us know which ones, so that they might get onto somebody's radar.

Thanks.
(0030930)
Brandon Van Every (reporter)
2012-09-05 16:39
edited on: 2012-09-05 16:49

My thought is, pushing a bug to the back of the bus after 2 months is just demoralizing. That's like, somebody blinked. 4 months might be ok. I think if 4 months have gone by, then the ball has definitely been dropped.

Other people need time to notice things on mailing lists, discover problems, talk about them, get up the gumption to lift a finger, convince others that it's worth doing, etc. For instance I am now interested in the robustness of FindGLUT and also adding a FindGLEW module, but I wasn't even doing any development relevant to that a month ago. I would like to get something deployed and tested before submitting solutions here. Also realize other communities aren't that swift about CMake and need some time and encouragement for things to sink in. The opengl.org ecology is certainly chaotic in that regard; they don't have great buildmasters. Nevertheless they have some ok buildmasters who use CMake and are somewhat motivated to get better.

Another concern is triage when a solution seems to have been provided. Anything claiming to actually solve a problem should be getting some kind of minimal attention. What if there's nothing else to do and the fix is as simple as the original poster said? I realize that determining that efficiently is a question. A "solution proposed?" checkbox might be helpful for triage.

(0030931)
David Cole (manager)
2012-09-05 16:44

Bug has interest, brought back to "new" and unassigned status.

On the module maintainer info page...
  http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]
...OpenGL and GLUT are not covered by any maintainers.
(0030932)
Rolf Eike Beer (developer)
2012-09-05 17:00

It would just work to do
  cmake -D "GLUT_ROOT_PATH=%GLUT_ROOT_PATH%" ...

on Windows, no? I'm not absolutely sure about the syntax, but something like that should work. Jona, can you test that?
(0030934)
Brandon Van Every (reporter)
2012-09-05 17:11
edited on: 2012-09-05 21:46

Work, probably yes (without looking at the code), but the point of a Find* module is to automate such things in an intelligent way. BTW the GLUT developers are using CMake now in their trunk build. I've pinged their developer mailing list about maintaining the module.

(0030944)
Brandon Van Every (reporter)
2012-09-06 12:49
edited on: 2012-09-06 12:57

GLUT_ROOT_PATH first appeared in the sources in 2002. http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindGLUT.cmake;hb=0b288b612119c551faa78644e7a1a7f395a78c98 [^] I can't find any evidence of it as an official GLUT or FreeGLUT environment variable. It's not in the GLUT PDF docs. http://www.opengl.org/resources/libraries/glut/glut-3.spec.pdf [^] FreeGLUT doesn't have any additional docs, they refer to the GLUT PDF docs. FreeGLUT doesn't have this variable in its sources AFAICT. I found other environment variables that were documented, so I think I did search the relevant source code.

It looks CMake specific. Why would it have been put in there? Did CMake at one point automatically generate <MODULENAME>_ROOT_PATH variables? I don't see such a behavior in the CMake docs. I do not find any current modules that follow such a convention. FindGLUT stands alone.

The module does not document it as an interface variable for a user to fill out. Do you suppose it was meant to be used as such, and it was simply never documented? The CMake module maintenance page talks about preserving both explicitly documented and implicitly not-really-documented variables at the beginnings of modules. The latter doesn't sound like a great practice, i.e. bug preservation. Especially, if FindGLUT has been seldom used in this way, maybe it's wise to get rid of GLUT_ROOT_PATH.

(0030948)
Rolf Eike Beer (developer)
2012-09-06 16:10

That what is in there is no environment variable, but a CMake variable (i.e. one set using "cmake -D ..."). I know there are some Find* modules using such variables (e.g. Boost), but by far not all. The usual way is to properly set CMAKE_PREFIX_PATH before calling CMake or set a CMake variable if there is any. Note that you can at any time override that has been found by directly specifying the library or include variable at the command line and override what has previously been found (i.e. cmake -D GLUT_glut_LIBRARY=c:/foo/bar/glut.lib ...).

So I think this patch fixes a problem where there is none, you already _can_ specify what you are searching for using 2 different working ways from the command line. No need to add a third IMHO (the current CMake variable would need to be kept for compatibility reasons).
(0030949)
Brandon Van Every (reporter)
2012-09-06 17:02

I agree that GLUT_ROOT_PATH should not be read from the environment. It is not a standard, expected variable according to GLUT and FreeGLUT documentation. When I became aware of this "bug," I thought it might be.

No module is using the convention <MODULENAME>_ROOT_PATH. Boost uses <MODULENAME>_ROOT and <MODULENAME>ROOT, and those uses are documented.

My personal opinion is, using inconsistent and undocumented variables as an interface harms the usability, maintainability, and reputation of CMake. It's darned annoying to always have to dig through MODULE.cmake code to figure out what's really going on, and most CMake newbies don't even know they need to do that. I realize that the FindOpenGL and FindGLUT modules lack maintainers, but stronger conventions would mitigate the need for such maintainers. Every module shouldn't be some special case doing everything all over again its own way, especially not for fairly simple libs like OpenGL and GLUT. I propose:

- decide on a "root path" naming convention that is consistent across all modules. Bless it and document it as the official way to do things.

- in FindGLUT, check for a definition from the old name, and accept an assignment from it, but issue a build warning that the old name is depreciated.

- I don't really care if all other modules are brought into "compliance," or if that is stretched out over time, but I hope other maintainers see the merit.
(0030950)
Brandon Van Every (reporter)
2012-09-06 17:54
edited on: 2012-09-06 19:21

CMake-2.8/Modules/readme.txt already advocates what I advocate. It says:

[quote]
Note to authors of FindXXX.cmake files
We would like all FindXXX.cmake files to produce consistent variable names.
Please use the following consistent variable names for general use.
[...]
XXX_ROOT_DIR Where to find the base directory of XXX.
[/quote]

XXX_ROOT is actually the most common convention, followed by a few XXX_ROOT_DIR. Unfortunately the CMake docs talk about CMAKE_FIND_ROOT_PATH, which might confuse some people. But admittedly it's a PATH specification and could contain multiple directories, so justifiably different.

I propose:
- decide whether XXX_ROOT or XXX_ROOT_DIR is to be preferred
- change FreeGLUT accordingly and document it at the top of the module
- test whether GLUT_ROOT_PATH exists and take an assignment from it, but issue a warning
- try to get other maintainers to bring other modules into compliance, using the same warning approach

Note that CMake-2.8/Modules/readme.txt first appeared in 2002, asking for module writers to use XXX_ROOT_DIR. http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/readme.txt;hb=63d64d5780aa189324800e70feb6345a73b8e8a3 [^] That was 10 years ago. Clearly, the request has been mostly ignored. I hope that provides motivation for issuing a warning, or some other "slightly more coercive" measure than simply leaving people to do whatever.

(0030955)
Brandon Van Every (reporter)
2012-09-07 12:56

Further investigation reveals:
- GLUT_ROOT_PATH is WIN32 specific
- as of FreeGLUT 2.8, searching for libs in ${GLUT_ROOT_PATH}/Release is wrong. They started using a /lib/Release directory. I say "wrong" because nobody's supposed to be using the original closed license GLUT library anymore, it is not maintained. People are supposed to be using FreeGLUT.

This GLUT_ROOT_PATH is nothing more than Windows-specific historical cruft. It should be depreciated and no XXX_ROOT or XXX_ROOT_DIR variable exposed. Code to do this:

if(GLUT_ROOT_PATH)
  message(WARNING "warning: GLUT_ROOT_PATH is depreciated. ")
  set(DEPRECIATED_WIN32_INCLUDE ${GLUT_ROOT_PATH}/include)
  set(DEPRECIATED_WIN32_RELEASE ${GLUT_ROOT_PATH}/Release)
endif()
  
IF (WIN32)
  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h
    PATHS ${DEPRECIATED_WIN32_INCLUDE})
  FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
    PATHS
    ${OPENGL_LIBRARY_DIR}
    ${DEPRECIATED_WIN32_RELEASE}
    )
ELSE (WIN32)
(0042067)
Kitware Robot (administrator)
2016-06-10 14:28

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2012-06-14 16:45 Jona New Issue
2012-08-11 21:42 David Cole Status new => backlog
2012-08-11 21:42 David Cole Note Added: 0030440
2012-09-05 09:25 Brandon Van Every Note Added: 0030925
2012-09-05 14:31 David Cole Note Added: 0030928
2012-09-05 16:39 Brandon Van Every Note Added: 0030930
2012-09-05 16:41 David Cole Status backlog => new
2012-09-05 16:43 Brandon Van Every Note Edited: 0030930
2012-09-05 16:44 David Cole Note Added: 0030931
2012-09-05 16:45 Brandon Van Every Note Edited: 0030930
2012-09-05 16:49 Brandon Van Every Note Edited: 0030930
2012-09-05 17:00 Rolf Eike Beer Note Added: 0030932
2012-09-05 17:11 Brandon Van Every Note Added: 0030934
2012-09-05 17:14 Brandon Van Every Note Edited: 0030934
2012-09-05 21:46 Brandon Van Every Note Edited: 0030934
2012-09-06 12:49 Brandon Van Every Note Added: 0030944
2012-09-06 12:56 Brandon Van Every Note Edited: 0030944
2012-09-06 12:57 Brandon Van Every Note Edited: 0030944
2012-09-06 16:10 Rolf Eike Beer Note Added: 0030948
2012-09-06 17:02 Brandon Van Every Note Added: 0030949
2012-09-06 17:54 Brandon Van Every Note Added: 0030950
2012-09-06 19:21 Brandon Van Every Note Edited: 0030950
2012-09-07 12:56 Brandon Van Every Note Added: 0030955
2016-06-10 14:28 Kitware Robot Note Added: 0042067
2016-06-10 14:28 Kitware Robot Status new => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team