<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Fri, 2010-09-17 at 15:27 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>I think you may have misunderstood: I don't write "the module set to a</TT> <TT>build.modules file to feed build.sh", I use the new "-L" option to</TT> <TT>build.sh to have it generate the list for me on-the-fly. So I'm not</TT> <TT>maintaining 3 files, just the two.</TT> </BLOCKQUOTE> Right, I had not paid enough attention. However, my point about the user interface still stands. This is introducing a second script for the user to perform the task. That leads to: - more instructions to read - more options to remember - more points of failure Some symptoms already:     echo "    -k|--keep-going   continue with next module despite failure" User has to tell the scripts twice the same information.     echo "this script expects to be run in a location"     echo "such that build.sh is located at ./util/modular" Additional points of failure due to multiple scripts invocation. I understand the drive to separate git vs build commands as build.sh got bloated with more features. Separating the implementation does not mean dragging the user in this exercise. Give this a try: keep the interface in build.sh and get some of the work done by xcmd.sh. From the user stand point, it's still one script and one interface to perform the task. This is a huge benefit for both the user and the implementor. The interface between build.sh and xcmd.sh is private and can change as needed with no impact to the user. Consider xcmd.sh the git backend to build.sh. Thanks for patience. I like what you are doing, it is important as all future contributors are directed to build.sh or jhbuild, so it has to be easy to use. Gaetan </BODY> </HTML>