Re: Moving creation of libtool/ltmain.sh to config.status

[Gary V . Vaughan]

I think I see a clean way to achieve this.

  i) The generated configure script writes the results of the C tests as
     ltcf.in and each tagged configuration out as ltcf-<TAGNAME>.in.
 ii) config.status makes libtool from ltcf.in + libtool.in + ltcf-*.in.
iii) We change the current make rule for rerunning configure, so that it
     rebuilds libtool with a call to config.status.

If we later want to use libtool in configure tests, it is a simple matter of 
skipping the tests if a stamp file is older than the libtool script, and 
having make rerun configure after touching the stamp file to have the 
additional tests execute on the rerun.

However, effectively this just moves the horrible hack out of the libtool 
sources and adds it back in to any macro that wants to perform configure time 
link tests.  Probably not a good thing to do. =(O|

Comments?

Cheers,
        Gary.

On Monday 16 July 2001 9:03 pm, Tim Van Holder wrote:
> > I am still unconvinced though.  It is config.status job to
> > generate files,
> > and automake (and make) would work better if config.status performed the
> > generation.
>
> Yes, but the main problem is that tags are appended to libtool, so
> you can't have some stock libtool.in that is transformed.  The patch
> I posted used two new build files, that are combined with ltmain.sh to
> form libtool using an AC_CONFIG_COMMAND; the other option is to build
> a libtool.in and let an AC_CONFIG_FILE transform it into libtool, but
> that requires AC_SUBST'ing a lot of variables (and as I've found out,
> the tag system isn't currently set up to properly cache each tag's version
> of the config vars, making this tricky.
>
> > This too would be improved by performing libtool generation in
> > config.status, the way it works now is pretty much a horrible hack.
>
> Agreed, but the fact that you append to libtool itself makes this hard.
> I suppose we could distribute a 'libtool.in' instead of ltmain.sh; that
> would basically be the default config vars (using @var@) followed by
> ltmain.sh as it exists now.  libtool.m4 could then strip any tag configs
> from this file during setup, and run as it does now, appending tag configs
> as appropriate (also using @var_TAG@).  Then autoconf could simply use
> its AC_SUBST machinery to create libtool.
> The libtool distribution would have a libtool.bootstrap or something,
> which corresponds to the current ltmain.in, that would have the package
> and timestamp substituted in at bootstrap time (and in the Makefile) to
> get libtool.in.
>
> Note: I am notorious for missing elegant solutions to problems, so there
> are quite likely some better solutions.
>
> > Autoconf-2.50 has lots of nice new machinery to make generation of
> > project specific files in config.status easy to achieve.
>
> True, but libtool is pretty special.  Of course, we could just wrap
> libtool.m4 in a giant AC_CONFIG_COMMANDS and have config.status (try to)
> do all of the libtool configuring.  But since autoconf isn't set up for
> such (ab)use, I expect this will be non-trivial as well.
>
> > Does autoconf-2.50 or higher have a way to schedule macroised
> > code to run in config.status, so that we could write a libtool.m4 macro
> > to save configure time libtool script based link tests until after
> > libtool has been built?
>
> You can use AC_CONFIG_COMMANDS to run any kind of commands in
> config.status, but most of the support variables aren't present in
> config.status (unless you explicitly emit them), and you can't AC_SUBST or
> AC_DEFINE inside config.status (as those affect how config.status is
> generated), making it pretty much useless for link tests.
>
>
> _______________________________________________
> Libtool-patches mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool-patches

-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/