[cmake-developers] [CMake 0013306]: findglut bug
Mantis Bug Tracker
mantis at public.kitware.com
Wed Sep 5 16:41:12 EDT 2012
The following issue is now in status NEW (again)
======================================================================
http://public.kitware.com/Bug/view.php?id=13306
======================================================================
Reported By: Jona
Assigned To:
======================================================================
Project: CMake
Issue ID: 13306
Category: Modules
Reproducibility: always
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 2012-06-14 16:45 EDT
Last Modified: 2012-09-05 16:41 EDT
======================================================================
Summary: findglut bug
Description:
I 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.
======================================================================
----------------------------------------------------------------------
(0030440) David Cole (manager) - 2012-08-11 21:42
http://public.kitware.com/Bug/view.php?id=13306#c30440
----------------------------------------------------------------------
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
http://public.kitware.com/Bug/view.php?id=13306#c30925
----------------------------------------------------------------------
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
http://public.kitware.com/Bug/view.php?id=13306#c30928
----------------------------------------------------------------------
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
http://public.kitware.com/Bug/view.php?id=13306#c30930
----------------------------------------------------------------------
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 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 how to determine that efficiently is a
question.
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 EveryNote Added: 0030925
2012-09-05 14:31 David Cole Note Added: 0030928
2012-09-05 16:39 Brandon Van EveryNote Added: 0030930
2012-09-05 16:41 David Cole Status backlog => new
======================================================================
More information about the cmake-developers
mailing list