Re: Cleanup initialization of configure process (issue 549350043 by address@hidden)

[dak]

On 2020/01/14 14:12:47, hahnjo wrote:
> On 2020/01/14 13:59:43, dak wrote:
> > On 2020/01/14 13:52:02, hahnjo wrote:
> > > Is this ok to push in its current revision?
> >
> > I am not overly happy that it makes for inoperative code in the case
of a
> > read-only repository that autogen.sh tries catering for.  Can/should
> autogen.sh
> > pass some sort of environment variable that this can be picked up
from in the
> > shell code executed for getting the version number?  Or is this
available in
> > some m4 variable one could pick up?

> As autoconf itself doesn't handle this case, I doubt there is a good
solution.

> > Maybe at least stick a #FIXIT comment into autogen.sh (and possibly
> > configure.ac) so that someone bumping into this has less trouble
figuring out
> > what went wrong?

> Sure can do. If nobody complains, maybe we could even consider
dropping support
> for autogen'ing a readonly source directory?

Well, it seems like making it inoperative and sticking FIXITs in there
is less of a clear signal (and possibly less likely to garner notice we
can react to) than it just failing to cater for it, and with version
control one can always resuscitate code that went absent.

So maybe just remove the code.  Or wait, you can replace

  configure=./configure
  conf_flags="--srcdir $srcdir $conf_flags"
  echo "Running autoconf for read-only source directory ..."
  autoconf -I "$srcdir" -o "$configure" "$srcdir/configure.ac" || exit 1

with

  echo "Running autoconf for read-only source directory not supported"
> &2
  exit 1

and if someone complains, we can still think how to fix it.  The
simplest version likely just being copying the VERSION file over before
running autoconf.  But before we install patchwork like that, let
someone complain that they were actually using the code.

https://codereview.appspot.com/549350043/