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

[Bruce Korb]

Alexandre Oliva wrote:
> ...
> - it makes it harder for someone who finds a problem in ltmain to
> attempt to fix it, since they get (in the final package) someone even
> farther from the original sources

As it stands, they only see the same script they see now.
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.  :-)
In the future, I anticipate abstracting the command line option
processing for the various "modes" into a table of sorts.
>From that table, I will derive a shell script and a program.
At the moment, the table and program are very simple (albeit large).

> - in order to compile something to run on the build machine, we need a
> BUILD compiler; CC won't do because it may be a cross compiler.  We
> may need a special `configure' step to (i) find a BUILD compiler, in
> case one is available, and (ii) detect properties of that
> compiler and build environment

A couple of options:
1) Have an installable libtool binary that does *not* ship with
   libtool client product.  Instead, libtool client configury
   detects its presence and uses it in preference to the bundled
   script.  It may need to be told of alternate config info in
   the event of a cross build.  Version detection may be needed, too.

2) Ship both the script and .c with client products.  If a cross
   build is configured with no findable build machine (non-cross)
   tools available, then the script is used.  Otherwise, build
   the binary.  It *could* be used in conjunction with an installed
   binary, too.  Probably harder to configure and certainly more
   baggage for client products.

3) Probably other permutations I'm not thinking of.

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.  In any event,
the maintenance of the command option handler table will be easier
to comprehend than the current billion line script.  (Witness the
inclhack.def file vs. the fixincludes script.)

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?

> I don't want to sound like I'd reject any proposal for a compiled
> ltmain (or maybe I'm just missing something obvious), but I fail to
> see how we could evolve this into something that would work better in
> C than as a shell-script.

"work better"?  Well, I guess that depends on definitions.  I assert,
"easier to maintain and comprehend".  Ultimately, 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

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