[PATCH build] Separate build and repository functions.

[Gaetan Nadon]

On Fri, 2010-09-17 at 17:24 -0400, Trevor Woerner wrote:

> 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? 

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.


> 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 <memsize at videotron.ca> 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).

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"





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100917/d008829e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100917/d008829e/attachment.pgp>