Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
a) it assumes the CVS directories exist (which is not
true in a source distribution)
b) the commands look for the CVS directory in the
build directory, not in the source directory
Logged In: YES
a) it assumes the CVS directories exist when the version is from CVS
(source distributions should not have date in minor_version)
in addition, the build dir is used for the temporary files (instead of the
srcdir) and version.h has been removed from CVS (it's generated, so it
really shouldn't have been there in the first place)
Logged In: YES
Sorry, but the make rule still says it depends on the CVS
directory which will be missing, so make will fail.
I changed the make rule so that all prerequisites are now
completely optional, and the commands doing all the work are
now in batch/version (so the build module can use the script
directly without a run of configure).
Also, version.h now is generated inside the source directory. It
will now be part of the distribution instead of this major/minor
BTW, the automatic date tag was a good idea. Like it.
Does the new code automatically rebuild version.h when the files change?
The reason version.h should be built outside of the srcdir is because it is
generated content and putting it there will break a read-only srcdir setup.
Perhaps we need a Makefile.cvs that runs autoconf and makes version.h?
Yes, the update rules should be unchanged.
Read only source directories should not be a problem; the
rules for configure and version.h should only run the update
commands when the source directory is from CVS.
A special makefile that is only included when the CVS
subdirectories exists may be a good idea; however, I think
we should keep the differences between a build from CVS
and a build from a source distribution to the bare minimum.
Tough decision, since the differences are already there, it's
just a question of how to handle them. Perhaps this should
be taken to the forum?