Re: Pending patches for generic build script

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Tue, 12 Oct 2004, Charles Wilson wrote:

> Whatever happened to the idea of getting rid of all the extraneous &&\
> crap in gbs?  Was the idea rejected, or forgotten?
> --
> Chuck

Neither.  Someone actively producing new package versions (i.e., not me)
was supposed to test it and make sure it works properly.  This would be
especially useful on packages that don't use external source and don't
require heavy modifications to the CVS version of the GBS.

I'm not quite sure how to best go about doing this -- either change the
GBS now and ask people to test it (and retract if they complain), or have
people make the changes themselves and submit a patch afterwards, or
create a CVS branch...  All three solutions have their drawbacks, but I'm
willing to make the actual changes in CVS if it's more convenient.  Any
takers?
	Igor

> Charles Wilson wrote:
>
> > Igor Pechtchanski wrote:
> >
> > > > false || true
> > > >
> > > > As a bonus, this construct documents that this particular line can
> > > > return a false value.
> > >
> > > I see.  Well, this does look reasonably readable...  Another problem
> > > with "set +e" that I vaguely recall reading about is that it may not
> > > always be propagated into functions...  If you're willing to test
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^
> > > this and make sure it always works properly, and if nobody else
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > protests, I'll consider patching the generic-build-script.
> >
> >
> > Yes, I've never liked the silly looking '&& \' syntax in the gbs.  If
> > propagation of 'set +e' into functions is a problem, then just have each
> > function re-do it...
> >
> >
> > mkdirs() {(
> >   set +e
> >   cd ${topdir}
> >   rm -fr ${objdir} ${instdir} ${srcinstdir} || true
> >   mkdir -p ${objdir}
> >   mkdir -p ${instdir}
> >   mkdir -p ${srcinstdir}
> > )}
> >
> > Plus, if the shell is changed from #!/bin/sh to #!/bin/bash, then you don't
> > need the subshell -- because 'pushd' is available.  (Yes, I know you could
> > do, even in sh, "CWD=`pwd`; cd ${topdir} ; .... ; cd ${CWD}" but there's
> > another reason...)
> >
> > I've noticed lately that sometimes, when launching configure from an
> > environment where SHELL is /bin/sh (==ash), I get weird, non-deterministic
> > errors:
> >
> > "error: invalid feature name: shared"
> >
> > when "--enable-shared" IS a valid feature for the package; but the error
> > doesn't show up ALL the time.  This issue is what's made me have to run
> > (portions) of the libtool test suite over and over before releasing it,
> > because many of the tests which fail will EVENTUALLY succeed.  Or, I just
> > configure with bash as my shell...the problem never seems to appear when
> > using bash.
> >
> > So, you could do:
> >
> > #!/bin/bash
> > set +e
> > ...
> > mkdirs() {
> >   set +e
> >   cd ${topdir}
> >   rm -fr ${objdir} ${instdir} ${srcinstdir} || true
> >   mkdir -p ${objdir}
> >   mkdir -p ${instdir}
> >   mkdir -p ${srcinstdir}
> > }

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw