On Sat, Feb 26, 2000 at 09:48:19PM -0300, Alexandre Oliva wrote:
> On Feb 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
>
> > making it relatively similar to bourne shell wouldn't hurt since that
> > is already a known quantity, and will be easier for maintainers to get
> > to grips with
>
> In fact, if we could keep it fully compatible with (a subset of)
> Bourne shell would be great. We might start by using shell functions,
> for example. Akim Demaille claims that there's no system in which one
> can't find a shell that doesn't support functions, even if that
> involves searching for alternatives automatically. In case we can't
> find such a shell, we could always make scripts out of the shell
> functions, and use them instead.
I wasn't sure I agreed with this for a while, but now that I have
mulled it over for a few days, I think it does make sense. In order
for the new language to be small enough to ship with libtool, I am
trying to avoid having a parser (which means flex and bison and large
generated C files); and by taking inspiration from scheme and tcl have
managed to come up with a very simple but powerful system.
I could be persuaded to add special support for `lval=constant', rather
than `set lval constant' as I have now, but I would *really* rather
avoid bournes quoting hell, so currently only balanced expressions are
catered for (`$(expression)' as opposed to ``expression`') since they
parse more easily and are easier to work with. You will have a very
hard time convincing me that we should trade that in for compatibility.
> Then, we could try to use enough of a subset of portable shell with
> functions so as to make it easily translatable to portable C. I
> believe it can be done, if we factor out enough of the low-level shell
> constructs into functions our translator would recognize.
That would be an excellent TODO list item for libtool-1.5/1.6!
> In this case, porting libtool to C, for the benefit of speed, wouldn't
> be that painful: it'd be just a matter of writing an appropriate
> translator. Not that it would be easy, but it wouldn't require us to
> re-implement everything from scratch, and we would just have to keep
> in sync the function definitions with their C-based counterparts.
Perhaps my prototype is less throwaway that I had imagined, since it
is completely modularized with libltdl which is exactly what we would
need.
The only flaw I see in your vision is that I can't see the point in
continuing to support a shell only version of libtool. As discussed
on the list already, the only (marginal) case where having a compiled
translator as part of libtool would be when cross compiling from an
environment with no host compiler -- and as Ezra rightly pointed out,
we could foster a binary distribution model for the `u' interpreter to
help these (very) few people use libtool-2.0.
Being able to make the transition gradually would be a huge win
though. I guess the thing to do would be to freeze the 1.x tree at
some point when the interpreter is ready, and concentrate on
translating the libtool shell code to `u'.
Come to think of it, autoconf would also see a huge leap in speed and
aintainability if it targetted `u' rather than shell, especially if it
also takes advantage of m4-1.5. Hairy m4 macros could be
reimplemented as m4-1.5 modules (though I suppose there would need to
be a parallel non-C implementation in this case), and hairy shell
constructs could be implemented as `u' modules. Losing the
portable-sh cruft would benefit autoconf as much (if not more) that
libtool... I'll concentrate on libtool-2.0 for the moment though =)O|
Cheers,
Gary.
--
___ _ ___ __ _ mailto:[EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
