Re: odd aclocal/automake depends issue

[Monty Taylor]

Ralf Wildenhues wrote:
> Hello Monty,
> 
> * Monty Taylor wrote on Tue, Dec 23, 2008 at 04:48:30AM CET:
>> First of all, the answer to my question is going to be "don't do that",
>> but just in case it isn't...
> 
> Nope, it isn't, AFAICS.
> 
>> The problem I was recently trying to solve is this: if I change a
>> plug.in file, automake doesn't trigger a re-run of aclocal, et al, Like
>> I would like it to.
> 
>> Next thing was to use sinclude to include the files (we had been using
>> builtin([include],$1) because of bug in aclocal 1.8. I _obviously_ don't
>> care about aclocal 1.8 anymore, so I ripped that out and used sinclude.
>> This now causes all the files to show up in am__aclocal_m4_deps. w00t!
>>
>> EXCEPT...
>>
>> Now, if I change and of the files, I get
>> Making all in innobase
>> cd ../.. && make  am--refresh
>> cd . && /bin/sh /Users/mordred/src/drizzle/devel/config/missing --run
>> aclocal-1.10 -I m4
>> make[3]: Nothing to be done for `all'.
>> Making all in myisam
>> cd ../.. && make  am--refresh
>> cd . && /bin/sh /Users/mordred/src/drizzle/devel/config/missing --run
>> aclocal-1.10 -I m4
> 
> Where are the plug.in files included from.  Please use m4_include or
> m4_sinclude rather than plain include/sinclude.  And then do the above
> and show the output of
>   aclocal-1.10 -I m4 --verbose
> 
> to find out better what is happening and which files aclocal is reading.
> aclocal should only not update the output file if it already thinks that
> it has an mtime that is greater than that of all of its input files (and
> if the contents match the would-be new contents).
> 
>> Am I doing something obviously wrong here? The behavior from sinclude()
>> is what I want in general, except for the extra rebuilding of aclocal
>> over and over again...
> 
> As a workaround, you should be able to use --force once, but of course
> that is not a fix.

Perhaps if aclocal make an aclocal-stamp which is what $(ACLOCAL_M4)
depends on, and make aclocal-stamp depend on $(am__aclocal_m4_deps).
then, am__configure_deps could just depend on $(ACLOCAL_M4) rather than
$(ACLOCAL_M4) and $(am__aclocal_m4_deps) ... so that aclocal can work
its magic and only update if necessary, prevent doing it more than once,
and configure can only re-do if needed...

Just a thought.
Monty