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

[Bruce Korb]

Alexandre Oliva wrote:
> 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.

As I have the hack configured now, it soaks up the configure.in
output (grabs variable definitions from the output libtool file)
and parses the same command line arguments.  So, the behavior
*does* depend on the configure.in stuff....

> Unfortunately, [improved maintenance is] 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 :-) :-)

I could be overly optimistic.  Not that unusual. ;-)  But, I *am*
pretty confident that the tables I describe are doable.

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

There would be an explosion of alternatives only if there were a need.
It is true I have an inclination towards the declarative side.  I want
it to be possible to specify what needs to happen for a particular
context (command option or environment) to be as simple as it can be.
(Unlike some of my sentences.;)  Those simple expressions drive whatever
complexity is necessary to create both a script and program:

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

OK.  I grabbed the default branch because it was handy.
What branch should I specify?  I would like to see the
*start* of the implementation immediately because it
will have no visible effect on the product but *will*
enable my branch to track updates.  :-)

Cheers,
        Bruce