[Scons-users] Scons-users Digest, Vol 5, Issue 21

[William Deegan]

John,

On Oct 29, 2012, at 9:00 AM, John Galbraith <jgalb at lanl.gov> wrote:


> Bill, this is a good suggestion and one I had not thought of.  It is not quite as elegant a solution to my eye, but it still works fine and is robust to crashes.

> 

> Also, it occured to me that true crashes are actually less frequent than my own kill signals, sent because I want to change something before the run finishes.  In this case, I might be able to catch the interrupt signal and shutdown gracefully.  I have done this exact thing in C++, I just have to figure it out for python.  I think the hard part is that you do not know in advance which thread gets the signal.  Signal handling and threading do not necessarily play nice, at least on Linux which is the only platform I know.

> 

> I still could totally go for a env.flush() mechanism…


I don't recommend too much magic (heavy lifting) in your SCons logic.
In addition to your issues, it makes it harder to test the new logic itself and/or run it outside of SCons, which may make debugging/etc easier.

-Bill


> 

> John

> 

> On 10/28/2012 02:52 AM, scons-users-request at scons.org wrote:

>> On Oct 24, 2012, at 10:09 AM, John Galbraith<jgalb at lanl.gov>  wrote:

>> 

>>> >

>>> >Is there any way for scons to protect itself from broken extension calls, and at least flush .sconsign before surrendering to no-fault flaming death?

>> So you're pulling your c extension into your SCons invocation and running it in process in SCons?

>> Sounds like generally a bad idea.

>> Make it run in a command run by SCons, that way if it crashes, SCons will still write a proper .sconsign

>> 

>> -Bill

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users