Since glew.h includes GL/glu.h (inside a #ifndef GLEW_NO_GLU) shouldn't glew.pc have a "Requires.private: glu" line?
Notice that I don't know why that #include is there to start with. I never used glew...
Traditionally #include <GL glew.h=""> has been "all of OpenGL, including GLU".
But recently we made it opt-out, since GLU is so old-school.
I don't think GLEW ought to "require" GLU, but code will break if
we make it opt-in, I expect.
So what to do?
From a Linux POV glibc sometimes also stops including e.g. stdio.h from stdlib.h and software starts failing to build. Nobody blames glibc for this, it's clearly the software's fault. IMHO the same applies here if someone uses GLU without #including it.
Notice that software is breaking anyway. If "glu-devel" is not installed a software that doesn't require GLU will fail to build because of the include in glew.h. That's how I noticed this!
If glew doesn't need glu at all then don't add that Requires.private, please. Just tell my if you want to keep the #include (then I will patch the failing packages in openSUSE to compile with GLEW_NO_GLU defined) or remove it (less work for me).
Agreed. I'll update the .pc accordingly.
Thanks for putting the argument so clearly. :-)
Fixed in git.
Actually in that argument so "clearly put" I was trying to argue for deleting the #include, not for modifying the .pc file :-p But it's OK, I don't care so much and it's also a valid fix.
Closing, resolved. Including GL/glu.h remains, for now...