> One point is automatically rebuilding the archetypes when the arch tree > changes. > > My thought here is that lib/Makefile can run svnversion and puts that in > a state file (.collect.svn.new). Then, the process compares that file with > the old one (.collect.svn) - if different, it runs the collect and moves > the file over. If the same, it just doesn't do anything. > > In this way, a collect would automatically be done whenever the > archetypes are updated.
Sounds like a good idea to me, if possible :) > I think similar logic could also be used to embed the version number into > the client and server binaries. That way, when someone reports a bug, it > is very clear what version they are running. By using a state file, it > means we don't need to recompile and relink everytime (if we just used > svnversion to blindly write a .c/.h file, then everytime it would recompile > and relink that component). Agreed, having the exact revision number would be really nice to see the exact issue. > In both of these cases, we also need to handle the case for the official > releases, where there will not be any SVN information in the downloaded > source code, and the user may not even have svn tools installed. Well, that's what tags/branches are for, i guess :) > In the case of lacking the svn data itself, I'd think the makefiles could > just check for .svn files - I'd rather not have to reconstruct the > makefiles for the official versions. In terms of the version string, I > think the file that inclues it would have to be part of the distributed > version so that it is there for the compiled in. Including the SVN version > in officially released distributions shouldn't cause any problems IMO. No issue for me either. Nicolas _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
