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

[Tim Van Holder]

> 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.

>  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?)

> 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.