libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO


From: Ralf Wildenhues
Subject: Re: TODO
Date: Wed, 10 Nov 2004 16:44:28 +0100
User-agent: Mutt/1.4.1i

* Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET:
> Peter O'Gorman wrote:
> > Gary V. Vaughan wrote:
> 
> >>> Post 2.0:
> > 
> >>> 1. Generate a libtool.m4 from a bunch of individual file, one per
> >>> platform, to make the job of a "platform maintainer" easier and make it
> >>> easier to add new platforms.
> >>
> >> Seems like a good idea, but I think it will prove difficult in
> >> practice -- unless we redo the way we have written all the macros.
> >>
> >> I think that it is a good enough idea to be worth discussing some more
> >> though.  How do you envision the architecture for parsing and using the
> >> platform chunks?

No idea, just a comment: /If/ you go through all the pain to redo the
platform chunks, and also change ltmain implementation, don't make it
so everything has to be changed twice.

[ xslt .. ]
>
> Gah, perl?  Blech.  XML?  Bah!  Choke...
> 
> <rant>
*snip*
> There... I've got it off my chest, and feel much better now :-)

/me agrees on everything you said except about perl.

> Libtool already depends on C, so we don't need to resort to Perl.  We can
> always prototype something in Perl, and then before we forget what all
> those strings of puntuation do, we should convert it to Shell and/or C.

Why prototype in perl what you can write in shell (or other) right away?

> I think that porting ltmain to C or a byte-compiled language of some sort
> is definitely a win all round, so we can probably come up with an
> implementation in whatever language ltmain gets rewritten in eventually.
> 
> I *do* think your idea fantastic idea btw... I guess the ball is in my
> court to figure out how we might do it without Perl and xslt now :-/  That'll
> teach me! :-o

My vote: against everything but shell and C for ltmain.  For the rules,
make might prove fine (except that the portable set is quite limited).
I'd do C++ (with STL), but that's out of the question portably-wise.

Regards,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]