Re: TODO

[Gary V. Vaughan]

Peter O'Gorman wrote:
> Hi Gary,

Howdy!

> 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?
> 
> 
> Well, I haven't thought about it really, I was vaguely imagining running
> a perl script during bootstrap which would take the bits and pieces and
> put them all together. I am told that xslt could do this too. The point
> being that we'd end up with the same (more or less) libtool.m4 as we
> have now, it would just be a heck of a lot easier to find the bits and
> pieces related to specific platforms, and would leave the platform
> independent stuff in a single file.

Gah, perl?  Blech.  XML?  Bah!  Choke...

<rant>
It is a pity that Autoconf and Automake have a dependency on Perl, because
that makes it easy to let it creep into Libtool.  I've tried to learn Perl
on at least two separate occasions, including buying and reading the entire
Camel book.  I can usually figure out roughly what's going on in someone
else's code with a bit of head scratching, but I still can't come up with
any maintainable code of my own.  TMTOWTDI?  TLTOWTUI! There's less than
one way to understand it!
</rant>

I'm also very wary of jumping on the... oh, wait:

<rant>
I'm also very wary of jumping on the XML bandwagon.  I know it's the latest
hip technology, and everyone wants in on the action, but XML is just lisp,
with ugly paired angle bracket blobs to replace the parens.
</rant>

There... I've got it off my chest, and feel much better now :-)

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.

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

>> 3.5.  While we are there, maybe internationalise libltdl?
> 
> I tend to agree with Ralf that we'd need to be careful that someone
> running libtoolize to get ltdl did not also get a requirement to have
> gettext.

Absolutely.  But I don't think it is a difficult problem to solve with
the more-or-less standard --disable-nls idiom.

>> 9.  Cross compilation test cases.
> 
> 
> Well, we just need lots and lots more test cases. We need platform
> specific test cases, platform indep test cases, test cases per bugfix
> (as Ralf did today), etc, etc.

Couldn't agree more!

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature