Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#22 [Tools] Consider creating a "tools" subproject.

Richard Rauch

OpenGLEAN has at least two tools that are certainly of
interest to the multiple sub-projects that OpenGLEAN
maintains, and may be of interest to others. They could
be rolled into a separate package, rather than
replicated across all (and only) OpenGLEAN projects.

One is dox.awk, which although quite limited, fills an
important niche of man-page generation for Doxygenated
projects. If and when Doxygen supports conventional
man-page generation, this AWK script may no longer be
needed. (dox.awk does not fully understand either C or
Doxygen, much less non-C languages.) But for now, I
would go so far as to say that it is vital for

The other is release.sh, the shell script by which I
generate releases. It is somewhat ad-hoc. I have to
manually track (somewhere) the version info for the
project, and still have to manually upload releases to
SourceForge. On the other hand, once set up for a
project, it does all of the edits (typically about a 10,
I guess) to get all of the right version numbers in the
right spot (libtool version, project version;
configure.ac, Doxygen files, HTML templates, ...), does
an optional CVS commit and an optional CVS tag
(consistent naming), then builds the distribution
archives and fingerprints them. Creating a SourceForge
release semi-automatically, and more intelligent version
tracking are both feasible additions. OpenGLUT can use
this (almost by definition, since I created release.sh's
ancestor for OpenGLUT releases) as can freeglut (very
similar structure), and probably several other projects.