Re: [Quilt-dev] [RFC] compatibility layer

[John Vandenberg]

On 9/18/05, Andreas Gruenbacher <address@hidden> wrote:
> Hello John,
> 
> On Saturday 17 September 2005 15:12, John Vandenberg wrote:
> > This patch introduces a `compat' directory, prefixed to the PATH.  The
> > directory is to be filled with workarounds that are included when
> > required.
> >
> > Three types of compatibility options are supported:
> >
> > symlinks: locations specifically chosen with --with-blah
> > programs.in: alternative scripts to emulate missing binaries
> > functions.sh: shell functions emulating missing binaries
> >
> > Included is one program (getopt) and two functions (mktemp and column)
> 
> Very nice, thanks a lot! I particularly like the configure.ac cleanup.

Thanks :)  The attached patch takes it one step further.  Each program
can have many functionality checks, and configure will fail, or fall
back, if any check fails.

> For the compatibility symlinks, you redefine the FOO variables in Makefile
> (e.g., BASH). This confused me a little before I realized what was going on.
> It's broken, too: you end up with relative paths in shebang lines (e.g., ``#!
> bash'' for ``#! @BASH@''). Relative paths in shebang lines are invalid. We
> should instead get rid of @FOO@ substitutions in the scripts where we can.
> That's the cleanup we were heading for, anyway.

Oh, yes, I forgot about that.  O well, it was fun while it lasted.

> I think we can keep compat/ out of the path if the directory doesn't exist,
> and only create this directory when needed).

Sure.

> Not sure whether we need compatfns and functions.sh; those can as well remain
> as external programs IMHO. I would rather remove this again and convert the
> two bash snippets in compat/ to standalone scripts.

My crystal ball tells me that I am going to be using a lot of small
shell snippets, and they need not suffer the cost of invoking a shell.

For an example on MSYS, without a functional ln -s, each `symlink'
will need to be transformed into either a `program' or `function'; the
latter will be more efficient.  Also, MSYS has a hell of a time with
EOL's, and eventually I would like to support both unix and msdos
EOL's.  To do this, patch and diff need to alternate between MSYS and
GnuWin32 binaries depending on the EOL of the current workpit.

Having said that, the need to merge the functions is messy, so I won't
mind if you drop them.  Is it possible to " source @QUILT@/compat/*.sh
" ?

> > Three minor issues remain ..
> > 1) $(BASH) in Makefile.in using --with-bash=... will be 'bash' rather
> > than $withval.  This should be solved by include compat/ in the
> > Makefile PATH
> 
> This is also resolved by not redefining those variables. We should rather do
> that.

No problems here, one less task to do.

> > 2) older autoconf not support; a little m4 sugar can solve this.
> 
> I don't think we do care. People with an old autoconf can choose to either not
> mess with configure.ac, or get a more recent autoconf. Depending on a recent
> version of autoconf is common practice.

Maybe I am sadistic, but I use 2.13 whenever possible.

> > 3) ln -s is not useful on MSYS, but I doubt anybody is clamouring for
> > that at the moment :)
> 
> Yes, this is a separate issue ;-)
> 
> So I think we should include the following patch on top of yours, replace
> instances @BASH@ and @INSTALL@ with $(BASH) and $(INSTALL) in Makefile, and
> then go on and replace obsoleted @FOO@ instances from all the scripts.

Agreed.  Thank you for the review and cleanups.

The attached patch includes your improvements, fixes the @FOO@ in
Makefiles, but leaves quilt/*.in alone.

wrt compat2.diff, dropping the symlink redefinitions means that the
install-compat-symlink-* rules can be rewritten.  They were separate
rules before the redefines because from that point on, the symlink
destination would be irretrievably lost.  Now, they can be moved down
into the install-compat rule, and the eval( ) can be dropped.
--
John

compat.diff
Description: Binary data