autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#8111: after adding a(nother) subconfigure, rerunning make fails


From: Jack Kelly
Subject: Re: bug#8111: after adding a(nother) subconfigure, rerunning make fails
Date: Sat, 26 Feb 2011 08:38:39 +1100

On Sat, Feb 26, 2011 at 7:46 AM, Ralf Wildenhues <address@hidden> wrote:
> [ adding autoconf-patches; this is <http://debbugs.gnu.org/8111> ]
>
> * Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET:
>> On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote:
>> > Can we fix this somehow in either Autoconf or Automake?
>>
>> Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If
>> there's a change, invoke ./config.status --recheck. If not,
>> config.status --recheck --no-recursion.
>
> Well, the rule that invokes 'config.status --recheck', let's call it the
> config.status rule, does not invoke any autotools, thus no m4.  Any
> rule that invokes m4 must be a developer rule, but the config.status
> rule is a user rule, which is even in place with maintainer-mode.
> So we cannot mix these two concepts.

If they are changing `configure.ac', they will be invoking developer
rules. I don't mean trace in the ./config.status --recheck rule, but
instead at `automake' time:

If there are any AC_CONFIG_SUBDIRS calls, write them out to a trace
file (such as build-aux/subdirs.trace). Save the previous trace as
build-aux/subdirs.trace.old. Now the rule to call config.status
--recheck needs to only run `diff'.

Having clarified myself, I think your method makes more sense (and has
no additional files to dist). Comments on that below.

> Since 'makefile' might be spelt in various different
> ways, we can take presence of 'config.status' in the subdir build tree
> as indicator, that should be good enough.

You should add a comment to this effect in your status.m4 changes.
Currently, it looks like you've tested for config.status by mistake.

> I'm still wondering whether we should rename the option
> --new-recursion-only however, that would be more precise.
> Other than that, the patch below seems to do what I want.

Yes. the name becomes very confusing. Maybe --recursion=no (with
--no-recursion as an alias), --recursion=new-only?

-- Jack



reply via email to

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