On Fri, 2010-09-17 at 14:13 -0400, Trevor Woerner wrote: > > Pull out the repository (i.e. git) functionality from the build > script. > Provide a separate script for running arbitrary commands in each of > the > modules which are built.
I like the idea, but not how it is implemented. Guess what, we use to have 2 scripts, one to do clone/pull and build.sh without git operations. Do you know why the git functionality has been merged into build.sh? Because each script contained it's own list of modules which is a pain to maintain. You intuitively bridged the gap by writing the module set to a build.modules file to feed build.sh. That's one step forward compared to what we had. The downer is that the user would now have 3 files to worry about and how they relate to each other. Each script having its own set of options to memorize. You need to write instructions and so on. Consider future extensibility, what if you want to use sed to make global changes to a larger set of modules, or run lint-like script to report possible Makefile issues. I came close to making a suggestion, as I have been thinking about this for a while. The angle I was contemplating is to isolate the module list in file (data only) and have as many scripts as required to provide as many features as desired. All directed from build.sh with one easy to use interface. The module list can be generated in the case of first time use. I think jhbuild uses this concept of module set. In build.sh, having just one module list does not suit all purposes. There could be a list for those who only want to build the server and its dependencies. This is a bigger project than it looks, but we are at that point where build.sh can hardly be improved without significant rework if we want to keep its ease of use. If you add pluggable module list and a unified user interface to what you did, it would complete the picture. Gaetan
git_xorg.sh
Description: application/shellscript
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
