with GNU build system

[josch]

https://sourceforge.net/p/glui/patches/5/

original report

It has come to my attention again that some users desire an easier way to install and use GLUI.

A while back I had modified the build system of GLUI v2.2 to use autoconf, automake, and libtool. I neglected to post it to this tracker... sorry. I am posting it now in hopes that build system has not diverged much, and as such it will be useful.

I could probably be coerced into doing this for the current GLUI subversion revision.

... Nevermind, sourceforge has a file size limit. You can obtain the tarball at

https://artemis.sr.unh.edu/~tfogal/glui-2.2.tar.gz

reply 1

This is pretty important enhancement IMO. There are several parts of makefile that require hand-editing and tweaking that oculd be simplified and made more user-friendly and platform-portable. The autotools know which -g and -O flags are good on which platforms. There are easy ways to do flags to (for example) select among the various glut types, and check for their presence and location. As it becomes necessary to use different #include or other things on different platforms or versions of operating system, it's easy to detect and automatically compensate. Libtool would bring shared-library support and the idea of interface compatibility. And there would be an easy way to install the lib, rather than relying on manually copying files (which ones? where?).

[nigels-com]

I think the cmake build ought to suffice, personally.

[josch]

Yes, probably. But as long as it works I plan to leave the original Makefile around.

I picked CMake instead of autotools because it supports generating Visual Studio projects for Windows.

But that CMakeLists.txt is still missing some targtets to generate the documentation for example. I'll close this bug once CMake support is complete.

[nigels-com]

I did give Windows a try, but I'm not sure what to do with freeglut for cmake to find it. Any suggestions?

[josch]

On windows, the cmake variables GLUT_glut_LIBRARY and GLUT_INCLUDE_DIR have to be set manually in the cmake gui if either are not placed in the standard lookup paths (and they should probably not be put there in the first place).

[nigels-com]

Oh, that makes sense. Duh! :-)