Add INTERFACE definition GLEW_NO_GLU for glew_head.h

[WangWeiLin-MV]

Add public compile definitions to glew-targets.cmake for https://github.com/nigels-com/glew/blob/master/auto/src/glew_head.h#L1131

Fix microsoft/vcpkg#43641 (comment)

Possible effects:

• Option GPU_ENABLED build failed: SiftGPU requires dependency GLUT colmap/colmap#3144

[nigels-com]

Looks good.

[dg0yt]

This ignores the generated pkg-config.
(It also doesn't reach users of CMake's FindGLEW.)
And documentation still claims that glew.h include glu.h.

glew/doc/install.html

Lines 158 to 159 in 3da315c

	In addition, <tt>glew.h</tt> includes <tt>glu.h</tt>, so you do not
	need to include it separately.

[dg0yt]

Suggested change

	target_compile_definitions(${t} INTERFACE GLEW_NO_GLU)
	target_compile_definitions(${t} PUBLIC GLEW_NO_GLU)

and remove the directory-scoped definition instead.

[nigels-com]

This ignores the generated pkg-config.

Indeed. There is a nuance with this, from my point of view. The official release of GLEW does indeed continue the (arguably obsolete) glu.h dependency for compatibility reasons. That's the compatibility story. Old client code depending on GLU ought to continue building and linking.

The cmake is opt-in and (as I recall the previous discussion) more free to behave in a contemporary, convenient, modernised manner. For modern or new code using cmake and GLEW I do think GLEW_NO_GLU is a reasonable assumption, and most likely what most people want in practice.

We could discuss the merits of that nuance in the context of the realities of 2025. But I did want to point out this somewhat convoluted way for compatibility and modernity to coexist reasonably and pragmatically.

It's also one reason the two builds continue along side each other, to serve those different needs.

Edit: And thanks for the review, always happy to have additional eyes on changes.