Re: Problem regenerating file removed by rule

[Darren Hiebert (Contractor)]

On Thu, 7 Apr 2005, Boris Kolpackov wrote:

> "Darren Hiebert (Contractor)" <address@hidden> writes:
>
> > The problem is that the the config.sh created by the first
> > invocation of make is removed by the third-party compiler during the
> > second invocation of make, and make does not rebuild it from the
> > existing rules, even though I have a dependency to create it again
> > after the third-party compiler runs
>
> First thing, in your script that emulates your compiler there is nothing
> that deletes config.sh. Let's assume that it does delete it however.

Actually, the script that emulates the compiler DOES remove
sub/config.sh (as well as sub/Makefile) since it removes the entire
'sub' directory containing them.

> The general rule is that if you do something behind make's back all
> sorts of bad things happen. In your case, the rule deletes the file
> that make is keeping track of; make has no idea this happened and
> there is no way to tell make about this.

But I don't understand why make doesn't regenerate config.sh itself
by executing its command, since its prerequisites were out of date,
necessitating that their commands be run, in turn. Yes, one of those
prerequisites' commands removed the pre-existing sub/config.sh, but
it seems that make should still be executing the command for
bringing sub/config.sh up to date based upon how I understand make
applies rules.

> I think your best bet is to try and make the situation as close
> to the fact that config.sh hasn't been deleted as possible. First
> thing to do is backup the config.sh before executing the compiler
> and then restore it, something like this.
>
>
> epr: source
>         cp config.sh config.sh.backup
>         $(third_party_compiler)
>        mv config.sh.backup config.sh

The problem with this suggestion is that the command executing the
compiler is simplified. The compiler can do incremental compilation
to byte code, in which case it does not regenerate the sub/config.sh
file which would lead to need to invoke the sub/Makefile. In other
words, the compiler can short-cut the process requiring that nothing
be done after it is run. Thus, the steps following the compiler are
conditional based upon examining sub/Makefile.SH after the
invocation of the compiler.

> The second thing you need to do is to make sure none of the rules
> that depend on config.sh run during the execution of your compiler
> (happens when make -j ); they can run before or after. You can use
> order-only prerequisites for that. Undoubtfully, the whole thing
> will be very messy.

But, as I understand it, I have already done what you are
suggesting, since sub/config.sh depends upon sub/Makefile.SH which,
in turn, depends upon epr (containing the compiler command). Therefore,
the rule for sub/config.sh cannot finish evaluation until the rule
for the compiler has completed evaluation.

To sum it up, it seems that make has completed its evaluation of the
rule for sub/config.sh by the time the compiler has executed, even
though I have tried to design the makefile such that those rule
cannot complete evaluation until AFTER the compiler has executed
(would you agree that the rule for sub/config.sh should ensure
this)?

Can you tell me why any of the assertions I have made in this email
are not correct (they must somehow be wrong, or I wouldn't have a
problem)?

Thank you,
Darren

--
Darren Hiebert
Phone: 256-964-5830
Pager: 877-214-3485
XonTech Systems
Missle Defense Division
Northrop Grumman Mission Systems