On Thu, 7 Apr 2005, Boris Kolpackov wrote:
"Darren Hiebert (Contractor)" <[EMAIL PROTECTED]> 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
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
