Re: re-re-re-re-re-re-configuring

[Nathanael Nerode <neroden at twcny dot rr dot com>]

>> And the reason I didn't do this was due to a different bug.
>> If libiberty is changed, then since
>> configure-bfd: configure-libiberty
>> configure-bfd: bfd/Makefile
>> 
>> bfd/Makefile won't be regenerated.
>
>But I tested that specific case, and it worked fine.
>
>I'll try it again.  Full build twice, second time nothing happens.
>Remove libiberty/Makefile and "make" again...
>
>$ grep 'Configuring in' /tmp/foo
>Configuring in libiberty
>Configuring in opcodes
>Configuring in bfd
>Configuring in binutils
>Configuring in gas
>Configuring in ld
>Configuring in gprof
>Configuring in etc
>Configuring in utils
>
>Same thing if I just do "touch libiberty/Makefile".
>
>I wonder if it's something gnu-make specific.
>
>No, wait... bfd/Makefile depends on opcodes/Makefile, which then
>depends on libiberty/Makefile.
To second-guess myself :-)... I don't see that in the Makefile currently 
in src and bib.
configure-bib: maybe-configure-opcodes
maybe-configure-opcodes: configure-opcodes
configure-opcodes: maybe-configure-libiberty
maybe-configure-libiberty: configure-libiberty
configure-libiberty: libiberty/Makefile

So maybe it does actually work? :-/  Can't imagine why it would, given 
that I actually hit this problem in an earlier version.

>
>Ok, feel free to change all the configure:configure dependencies to
>Makefile:Makefile dependencies.

I will as soon as I can resolve a related problem which I just realized:
namely, the 'maybe' dependencies are phony and therefore will generate 
the same problems.  I have to use direct substitution, a la putting

maybe_configure_opcodes=configure-opcodes
AC_SUBST($maybe_configure_opcodes)

So it might take a little bit...

--Nathanael