[Top][All Lists]

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

Re: OK. Here's the prototype ltmain.c....

From: Alexandre Oliva
Subject: Re: OK. Here's the prototype ltmain.c....
Date: 12 Oct 2000 16:30:15 -0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

On Oct 12, 2000, Bruce Korb <address@hidden> wrote:

> If they propose a fix, I do not think it very hard to determine
> which of the lt_*.def files contains the original text.
> The pieces are mostly separated by a " mode$" pattern.  :-)

It sounds like we have a volunteer :-) :-)

> 2) Ship both the script and .c with client products.

I think that's the only reasonable solution.  There could be some
declaration in that would cause the script to be omitted
(something like AC_NO_CROSS, that would reject any attempt to cross

> I think I like pure option #1.  A package will always have its shell
> script implementation as fallback, but if a build environment has
> installed the binary, they get a huge pay back in build times.

I doubt it's that much pay back.  Also, you have to bear in mind that
default behaviors of libtool change depending on macros called in and arguments given to configure.  So a pre-compiled
libtool can't be used in general.

> How about if I add a ``--mode=bug'' to ltmain and cause it to
> get some information from the user and package up a bug report,
> replete with attachments and config information?

We seldom get bug reports like that.  Much more often, we get requests
for enhancements, new ports, fixes or suggestions.

>> I fail to see how we could evolve this into something that would
>> work better in C than as a shell-script.

> "work better"?

Not a good word choice, indeed.  I meant I'm not sure the added
complexity of maintenance would pay off the potential gains in
run-time speed.  But then, libtool is barely maintainable as it is, so
any efforts to move it to higher level constructs is welcome.
Unfortunately, that's not what I see in your proposed implementation;
pretty much everything is still there.  But, as you say, it's just a
start, maybe it can be worked out, and I'm just being overly
pessimistic.  Not that unusual :-) :-)

> there ought to be
> some sort of table that says for a given command line option to one
> of the supported build tools; or for a given build environment state
> (e.g. shared libs or no shared libs):

>   1.  do something (a scriptlet) before the command runs
>   2.  transform the argument in a well specified way
>   3.  do something after the command runs

I fear an explosion of alternatives, that could only be worked out in
an imperative language, as opposed to the declarative nature I see in

> Each of these would have an implementation in both C and Bourne shell
> that would produce identical results.

This will be excellent.

But I guess we should start from the multi-language branch of libtool,
aiming at a 1.6 or 2.0 release.  Let's not fork off another
development branch from 1.4 (mainline), since this will only cause 1.5
(multi-language) to be delayed, maybe indefinitely.  I'd love to see
1.4 out of the door in the very near future, and 1.5 shortly

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist    *Please* write to mailing lists, not to me

reply via email to

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