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

> From: Trevor Woerner <[email protected]>
> 
> The build.sh script can now accept any arbitrary git or make commands from
> the user via the "--cmd" command-line argument. If no such argument is
> provided "make" followed by "make install" is assumed.
> 
> Signed-off-by: Trevor Woerner <[email protected]>
> ---
>  build.sh |   79 +++++++++++++++++++++++++++++++++----------------------------
>  1 files changed, 43 insertions(+), 36 deletions(-)
> 
> diff --git a/build.sh b/build.sh
> index c01a0d8..2b18390 100755
> --- a/build.sh
> +++ b/build.sh
> @@ -218,7 +218,7 @@ build() {
>          return
>      fi
>  
> -    echo "Building $1 module component $2..."
> +    echo "Processing module/component \"$1/$2\""

I like the above, but it is not related to the --cmd patch. One patch,
one logical change.

>      if [ X"$BUILT_MODULES_FILE" != X ]; then
>          echo "$1/$2" >> $BUILT_MODULES_FILE
> @@ -227,8 +227,18 @@ build() {
>      old_pwd=`pwd`
>      cd $SRCDIR || failed cd1 $1 $2
>  
> -    if [ X"$PULL" != X ]; then
> -     git pull --rebase || failed "git pull" $1 $2
> +    if [ X"$GITCMD" != X ]; then
> +     $GITCMD
> +     if [ $? -ne 0 ]; then
> +         failed "$GITCMD" $1 $2
> +     fi
> +     cd $old_pwd
> +
> +     if [ X"$BUILD_ONE" != X ]; then
> +         echo "Single-component git command complete"
> +         exit 0
> +     fi
> +     return 0
>      fi
>  
>      # Build outside source directory
> @@ -260,21 +270,13 @@ build() {
>           ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS" || \
>           failed ${CONFCMD} $1 $2
>      fi
> -    ${MAKE} $MAKEFLAGS || failed make $1 $2
> -    if [ X"$CHECK" != X ]; then
> -        ${MAKE} $MAKEFLAGS check || failed check $1 $2
> -    fi
> -    if [ X"$CLEAN" != X ]; then
> -     ${MAKE} $MAKEFLAGS clean || failed clean $1 $2
> -    fi
> -    if [ X"$DIST" != X ]; then
> -     ${MAKE} $MAKEFLAGS dist || failed dist $1 $2
> -    fi
> -    if [ X"$DISTCHECK" != X ]; then
> -     ${MAKE} $MAKEFLAGS distcheck || failed distcheck $1 $2
> +    if [ X"$MAKECMD" = X ]; then
> +     ${MAKE} $MAKEFLAGS || failed make $1 $2
> +     $SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install 
> || \
> +         failed install $1 $2
> +    else
> +     $MAKECMD || failed "$MAKECMD" $1 $2
>      fi
> -    $SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install || 
> \
> -     failed install $1 $2
>  
>      cd ${old_pwd}
>  
> @@ -721,9 +723,8 @@ usage() {
>      echo "  where options are:"
>      echo "  -a : do NOT run auto config tools (autogen.sh, configure)"
>      echo "  -b : use .build.$HAVE_ARCH build directory"
> -    echo "  -c : run make clean in addition to others"
> -    echo "  -d : run make distcheck in addition to others"
> -    echo "  -D : run make dist in addition to others"
> +    echo "  --cmd <cmd> : run an arbitrary 'git' or 'make' command"

The long options are grouped at the end.

> +    echo "                (default: \"make; make install\")"
>      echo "  -f file: append module being built to file. The last line of 
> this"
>      echo "           file can be used for resuming with -r."
>      echo "  -g : build with debug information"
> @@ -731,12 +732,10 @@ usage() {
>      echo "  -l : build libraries only (i.e. no drivers, no docs, etc.)"
>      echo "  -n : do not quit after error; just print error message"
>      echo "  -o module/component : build just this component"
> -    echo "  -p : run git pull on each component"
>      echo "  -r module/component : resume building with this component"
>      echo "  -s sudo-command : sudo command to use"
>      echo "  --clone : clone non-existing repositories (uses \$GITROOT if 
> set)"
>      echo "  --autoresume file : autoresume from file"

Not your doing, but autoresume is in the wrong order. It should be above
--clone.
See commit 8eebfc62963aae556791cccd32e63fee537dea79
Can you fix in a separate patch? I can do it but, you know, rebasing...

> -    echo "  --check : run make check in addition to others"
>      echo ""
>      echo "Usage: $0 -L"
>      echo "  -L : just list modules to build"
> @@ -760,20 +759,31 @@ do
>       DIR_ARCH=".build.$HAVE_ARCH"
>       DIR_CONFIG=".."
>       ;;
> -    -c)
> -     CLEAN=1
> -     ;;
> -    --check)
> -     CHECK=1
> -     ;;
>      --clone)
>       CLONE=1
>       ;;
> -    -d)
> -     DISTCHECK=1
> -     ;;
> -    -D)
> -     DIST=1

Removal of existing options should be discussed separately.
Providing a generic way of performing tasks (the --cmd) does not mean
making it harder to perform common tasks. 
Not everyone knows automake in details, much less functions like "dist"
and "distcheck".

I could see the removal of --check. But that's my biased view.

Rather than -p, I see 2 options I used regularly: getting a status and
rebasing.
Something like --rebase and --status. 

> +    --cmd)
> +     shift
> +     cmd1=`echo $1 | cut -d' ' -f1`
> +     cmd2=`echo $1 | cut -d' ' -f2`
> +     if [ X"$cmd1" = X"git" ]; then
> +         if [ X"$cmd2" = X"clone" ]; then
> +             echo "The \"git clone\" command is handled with the --clone 
> cmdline arg"

I don't see a need to forbid the usage of "git clone". Just like we
should not forbid "make clean" if we
allow "-c" again. 

> +             echo ""
> +             usage
> +             exit 1
> +         else
> +             GITCMD=$1
> +         fi
> +     elif [ X"$cmd1" = X"make" ]; then
> +         MAKECMD=$1
> +     else
> +         echo "The script can only process 'make' or 'git' commands"
> +         echo "It can't process '$cmd1' commands"
> +         echo ""
> +         usage
> +         exit 1
> +     fi
>       ;;
>      -f)
>          shift
> @@ -799,9 +809,6 @@ do
>       RESUME=$1
>       BUILD_ONE=1
>       ;;
> -    -p)
> -     PULL=1
> -     ;;
>      -r)
>       shift
>       RESUME=$1


A patch series would be appropriate and make it easier to discuss the
different logical changes in this patch.

Attachment: 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

Reply via email to