On 9/18/05, Andreas Gruenbacher <[EMAIL PROTECTED]> 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
_______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
