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
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
