[tahoe-dev] [tahoe-lafs] #853: pycryptopp-related hang of unit tests on platforms using buggy Gnu as 2.20 (e.g. MinGW 5.1.x, Ubuntu Karmic)

[tahoe-lafs]

#853: pycryptopp-related hang of unit tests on platforms using buggy Gnu as 2.20
(e.g. MinGW 5.1.x, Ubuntu Karmic)
------------------------------+---------------------------------------------
     Reporter:  zooko         |       Owner:                                
         Type:  defect        |      Status:  closed                        
     Priority:  major         |   Milestone:  undecided                     
    Component:  code-network  |     Version:  1.5.0                         
   Resolution:  invalid       |    Keywords:  pycryptopp binutils x86-64 x86
Launchpad_bug:                |  
------------------------------+---------------------------------------------

Comment(by zooko):

 Well, the idea I floated above of attempting compilation, then test, then
 recompilation a different way if the test fails makes me think it is "too
 clever".  I could imagine a bug in that process leading to problems even
 when there isn't a bug in Crypto++!  On the other hand, I definitely think
 we should add a "quick start up self test" to pycryptopp and in fact I
 have already done so but I haven't committed to to pycryptopp trunk yet.
 Once that is in place then Tahoe-LAFS can import pycryptopp, execute the
 quick start-up self-test, and if it fails Tahoe-LAFS can exit quickly and
 loudly.

 What do you think?

 By the way there is an idiom in Python packaging which is to try compiling
 a native-code extension module and if the compilation fails (such as if
 there is no C compiler present, or some necessary header files are
 missing), then go ahead and use the pure-Python implementation of that
 module instead.  So maybe if we wanted to go down this route we could
 start by adapting that idiom.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/853#comment:21>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid