* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
> Ralf Wildenhues wrote:
> >
> > So could you please list the technical problems you see with this patch,
> > so I can fix them, if any?
>
> Starting to add new features on this side of the 2.0 release is like
> the road to hell (paved with good intentions, yet doesn't lead to
> somewhere we want to be).
Yes. You already mentioned that, and I did not object. But you
mentioned that *in addition to* some idiosyncracies, and I wanted to
know what they were.
> I don't strongly object to the patch. However, CVS M4 achieves exactly
> this in a much more elegant fashion by simply including its own wrapper
> script to set the module load path for uninstalled m4 to load modules
> from the build tree. It also sanitises the error output to make writing
> tests easier (something libtool wrapper scripts shouldn't do), and can
> be easily extended without adding complexity to the libtool code.
So you think having a wrapper for a wrapper is a better general solution
to the problem? Well, if I can tell correctly, this is what Behdad and
Bob and everyone has been using so far.
> #! /bin/sh
> # @configure_input@
> # Wrapper around a non installed m4 to make it work as an installed one.
>
> "@abs_top_builddir@/src/m4" \
> --module-directory="@abs_top_builddir@/modules" \
This part is fine, and can be achieved by my patch.
> ${1+"$@"} 2>/tmp/m4-$$
This is very very unfortunate for debugging. I won't see the output
when it appears, which is sometimes crucial for a debug session.
Besides the fact that this line is a rampant security hazard
(I do `ln -s /tmp/m4-1234 /home/gary/some/important/file' for a few
probably PIDs, and you'll be sorry).
> status=$?
Using the variable status is not portable, as is using ${1+"$@"} without
taking care of zsh.
> sed 's,^[^:]*[lt-]*m4[.ex]*:,m4:,' /tmp/m4-$$ >&2
I intend to fix the changed naming in libtool eventually, if possible.
(Using an executable wrapper is one possibility that would work for many
systems; having the relinked binary with the same name, but in another
subdirectory helps, too; for bash, we could cheaply use "exec -a"; but
all this is work still to do...)
So all I see with this wrapper is a definite advantage for fixing things
*inside* the libtool wrapper, and not moving this work to third parties.
Cheers,
Ralf
