On Thursday 12 April 2001 11:17 am, Akim Demaille wrote:
> >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> On Apr 11, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> >> We are about to write new tools, typically autom4te, on top of
> >> which autoheader, autoconf etc. will be rewritten. I'm fed up with
> >> addressing portability issues on the maintainer side.
>
> Alexandre> That's why we should have this portability library coded in
> Alexandre> m4sh. Instead of repeatedly fixing the same problems over
> Alexandre> and over, we should have them coded right once, and then
> Alexandre> used all over. This will not only document the portability
> Alexandre> problems and solutions, but also make it easier for us to
> Alexandre> fix problems whenever they're found, reduce the learning
> Alexandre> curve of candidate new maintainers, and introduce new
> Alexandre> foundations for portable scripting.
>
> Your claim does not apply IMHO.
I must say that it rings very true for me...
> The recent bug reports about
> autoconf.sh are exactly what I'm referring too: AWK is too weak a
> language for us to test the existence of a file, and AWK
> implementations disagree on what to do in such a case.
I used to like awk a lot, until I realised that it was actually only gawk
that I liked, and half my users couldn't run my code. However, the current
GNU M4 CVS can do all this and more. The downside is that someone has to
write loadable modules in C to implement the functionality. Since it uses
libltdl, any modules required by autoconf can be preloaded on hosts that
can't do dynamic loading. I am on the verge of a 1.5 release, and have been
for some time -- I just need to cleanup some ugliness in the code -- so there
need not be an issue of relying on unreleased tools. Autoconf already
requires GNU M4, and all of the technology for generating shell scripts from
m4sh is here.
> configure is not concerned by this.
?? I assume you mean autoconf should not need to worry about this.
> Because we need more, there is no reason to remain bound to sh.
Well, I still have my Sic project on the table. I have a prototype for the
runtime which will drastically improve the speed of shell scripts (at least
an order of magnitude by my rough measurements). The proof of concept for
the front end will allow heavy users of portable shell (e.g. configure and
libtool) to gradually migrate towards full sic syntax (i.e. functions,
arithmetic, libc calls etc) without undertaking a rewrite in a whole new
language. The cost will be that projects will need to ship with, and compile
the runtime before scripts will run -- much like we currently build libtool
from shipped components inside the project.
There is one big problem with this two pronged (M4 modules + Sic) approach...
I don't have much time to devote to Sic at the moment, and the code is not
yet functional enough to attract more users, so it represents a long term
commitment.
Although Perl offers the path of least resistance, I am not at all convinced
that it will prove to be the correct choice in the fullness of time.
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
