[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving creation of libtool/ltmain.sh to config.status
From: |
Gary V . Vaughan |
Subject: |
Re: Moving creation of libtool/ltmain.sh to config.status |
Date: |
Sun, 29 Jul 2001 18:26:03 +0100 |
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__/