libtool-patches
[Top][All Lists]
Advanced

[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: Mon, 30 Jul 2001 18:20:54 +0100

On Monday 30 July 2001 5:46 pm, Tim Van Holder wrote:
> > 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.
>
> OK - sounds good.  Automake will need to add 'ltcf.in ltcf-*.in' to
> its distclean rules for libtool.

Automake should be calling `libtool --mode=clean' to remove libtool 
droppings, so it is just a matter of beefing up the list of files libtool's 
clean mode removes.

> >  ii) config.status makes libtool from ltcf.in + libtool.in + ltcf-*.in.
>
> OK (do we need libtool.in, or could we stick with ltmain.sh?)

Yeah, sorry, ltmain.sh is good.  Notice that ltmain.sh is currently created 
by a make rule that does a few manual substitutions.  This rule will need to 
be replaced by an AC_OUTPUT_COMMANDS, which will in turn need to be executed 
before the libtool script is concatenated.

> > iii) We change the current make rule for rerunning configure, so that it
> >      rebuilds libtool with a call to config.status.
>
> OK.
>
> > 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|
>
> Yes - relying on make to re-run configure after libtool is built seems a
> bit hackish.  Then again,
>
> config.status: configure libtool
>       @if test -f $@; then \
>          $@ --recheck; \
>          $@; \
>        else \
>          echo "You must run configure first."; \
>        fi
>
> might be enough to handle this.  libtool is created by config.status,
> so it will be newer - this is enough to know that we need to rerun
> configure, and 'config.status --recheck' does just that.  We then
> run the newly-created to recreate the output files; all we'd need to
> do is make sure that libtool is not updated during the second run.

Works for me =)O|  I'm not sure Alexandre will buy into though...

Cheers,
        Gary.
-- 
  ())_. 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__/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]