On Wed, 23 Apr 2008, Eric Blake wrote:
> I'm not quite sure what is best to do here. It seems like the simplest
> wrapper might be this untested script (short enough to possibly be worth
> distributing without copyright notice, since adding the notice would
> double its size):
>
> #!/bin/sh
> if test "${GNULIB_SRCDIR+set}" != set ; then
> ~ GNULIB_SRCDIR=`sed -n 's/gnulib_dir = //p' < cfg.mk`
> fi
> if autom4te --language=m4sh -o bootstrap_inner \
> ~ "${GNULIB_SRCDIR}/bootstrap.m4sh" ; then
> ~ exec bootstrap_inner
> else
> ~ status=$?
> ~ echo "$0: Please follow the directions in README-hacking to" \
> ~ "bootstrap this package" >&2
> ~ (exit $status); exit $status
> fi
What about something like the following?
#!/bin/sh
# If you have trouble using this script, please see README-hacking.
if test "${GNULIB_SRCDIR+set}" != set ; then
GNULIB_SRCDIR=`sed -n 's/gnulib_dir = //p' < cfg.mk`
fi
if test -d "$GNULIB_SRCDIR"; then
rm -f bootstrap.m4sh
ln -s "$GNULIB_SRCDIR/bootstrap.m4sh" bootstrap.m4sh || exit 1
else
# git, wget, or cvs command to download bootstrap.m4sh || exit 1
fi
autom4te --language=m4sh -o bootstrap-inner bootstrap.m4sh || exit 1
exec bootstrap-inner
The main difference is that, if you haven't downloaded gnulib yet, you can
still run bootstrap. bootstrap will download enough to generate
bootstrap-inner, which will download the rest of gnulib just as the old
bootstrap does.
I'm new to git. I looked through git's help for a while, and I didn't
find a command to simply export a file from a remote repository. Maybe I
missed it. Regardless, wget can fetch from savannah. I think that will
be sufficient.
I also eliminated the README-hacking warning. I figured its main purpose
was to help the user who doesn't know about downloading gnulib, but that
download is handled automatically now.
> This isn't very robust to failure. But the more robust you make it, the
> more it argues for having a single bootstrap script in the first place.
I agree. Moreover, if it stays short and conceptually simple (just do
enough to generate bootstrap-inner and run it), I see no need to add a lot
of careful diagnostics because project developers can then easily diagnose
failures themselves.
> Should bootstrap maintain both bootstrap.m4sh and the generated bootstrap?
By eventually creating a symlink to the bootstrap.m4sh within the full
gnulib download, I think my approach takes care of this.
> ~ Should projects that want to use gnulib's bootstrap also check it into
> their own repository, or just use the README files to inform users that
> their package can't be bootstrapped until gnulib's bootstrap file is run?
I don't see a need for either. Provided the user has basic tools
(autoconf, wget, etc.), he merely runs ./bootstrap.
If a project wants to maintain its own version of bootstrap.m4sh and
periodically perform a manual sync with gnulib's, it can by rewriting its
outer bootstrap not to use gnulib's. A better approach would be to extend
its outer bootstrap to perform whatever additional tasks that specific
project needs after running gnulib's bootstrap. Even better would be to
contribute to gnulib.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
