<!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 17:24 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <PRE> I like what I think you are suggesting. Are you suggesting you'd like to see a patch where I add the functionality xcmd.sh into the existing build.sh? </PRE> </BLOCKQUOTE> Not the implementation, just the interface. You used the concept of interface/implementation separation when xcdm used build.sh to get a list of modules. The user interface for the cloning task is on xcmd, but xcmd could not do all the job on its own. It delegated work (implementation) to build.sh without user intervention or awareness. Just turn the table around. Let build.sh contain all the user interface (options) to perform all tasks, cloning, building, you name it. The build.sh cannot do all the work so it delegates the git commands to xcmd, it's git "backend". Both cloning and building appear to the user as being done by build.sh. That's a single point of service to the user. He does not have to repeat information twice (see my comment below). I have seen this pattern with xmlto, for example. It uses various backends (html, pdf, etc...) to convert the xml format into pdf, html, etc...  It saves you from learning one command with their options for each output format. Another way to put it, what I propose is that xcmd and build.sh are not siblings, but build.sh is parent and xcmd is child, a background worker. The user plays around with build.sh, and never sees xcmd. So xcmd could be renamed (with a matching change in build.sh) and nobody would notice. That gives you, the implementor a lot of freedom to change the background worker without affecting the public interface. When you add new features to build.sh, you add an option (say --xserver=v1.9) to build.sh. That's all the user sees. It could be implemented in build.sh, xcdm or whatever script you want. The user does not care. <BLOCKQUOTE TYPE=CITE> <PRE> If so I'll give that a whirl otherwise I'll need to re-read your emails more carefully :-) On Fri, Sep 17, 2010 at 4:17 PM, Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> wrote: >     echo "    -k|--keep-going   continue with next module despite failure" > > User has to tell the scripts twice the same information. I'm not sure I understand your suggestion here. In my help notation I'm giving the user the choice of using either a "-k" option or a "--keep-going" option both of which do the exact same thing. This is exactly what "make" accepts as options. build.sh has a "-n" option which is equivalent. I chose "-k | --keep-going" to keep it similar to "make". But you don't have to specify both the "-k" and "--keep-going" options (you could, if you wanted to, but either one by itself would be fine). </PRE> </BLOCKQUOTE> I meant that for a single task, e.g building from scratch,  a user has to tell xcmd "keep going in case of errors"  and has to tell build.sh "keep going in case of errors". This is providing the same information twice, one to xcmd and one to build.sh. You might say it's normal because there are 2 scripts and I would say that's exactly the problem. One task, 2 scripts. Thanks again for listening! That would be the marketing statement for your proposal: "Separate build and repository functions while keeping a single easy to use interface" </BODY> </HTML>