|
Awesome, I think I've got the desired behavior going!
I was having trouble--even after reloading the global macros file via script--getting the other build machine to "unlearn" the existence of the %UPDATING_GLOBAL_MACROS_FILE%--even though the macro no longer existed in the .macros file on disk, it was still acting as though it was still defined and thus wouldn't exit my loop (I guess it was still in memory). I got around this by making %UPDATING_GLOBAL_MACROS_FILE% a permanent global macro and now flip its state between True and False when one machine needs to update it.
That being said, I modified steps 1 through 4 in my last post so that the updates to my global macros are handled exclusively via calls to separate VBP build scripts.
I have 3 such external scripts: one to set %UPDATING_GLOBAL_MACROS_FILE% =True (in order to lock the file), one that various procedures call to update my "comparison" macros, and another to set %UPDATING_GLOBAL_MACROS_FILE% = False.
I broke it out the %UPDATING_GLOBAL_MACROS_FILE% state-setting scripts this way so that there's as little time as possible between the macro value update and when it gets saved to disk. I just finished running through the same debug scenarios that were tripping me up yesterday and can no longer "break" it--it's entering and exiting the "wait for %UPDATING_GLOBAL_MACROS_FILE% = False" loop appropriately.
Thanks kinook for this fantastic solution!
If anyone sees any potential holes in this latest attempt please let me know.
--jdavidi
|