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

[Alexandre Oliva]

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 configure.in that would cause the script to be omitted
(something like AC_NO_CROSS, that would reject any attempt to cross
compilation)

> 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
configure.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
autogen.

> 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
thereafter.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me