Author jsjgruber
Recipients eric.araujo, jsjgruber, tarek
Date 2011-04-27.15:09:53
SpamBayes Score 3.1335e-05
Marked as misclassified No
Message-id <1303916995.82.0.476368226289.issue11933@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for considering my report so quickly. Attached is a simple test to reproduce the bug, as you suggested. 

Please note that I am not suggesting the code base use stat.st_mtime.

Running the attached with ext4, which keeps sub-second file timestamps:

gruber@gruber-Satellite-L355D:~$ ~/setuptest
running build
running build_py
creating build
creating build/lib.linux-i686-2.7
copying charley.py -> build/lib.linux-i686-2.7
running build
running build_py
copying charley.py -> build/lib.linux-i686-2.7

Under an ext3 filesystem which only accounts to the nearest second:

gruber@gruber-Satellite-L355D:~$ pushd /media/EXT3/
/media/EXT3 ~
gruber@gruber-Satellite-L355D:/media/EXT3$ ~/setuptest
running build
running build_py
copying charley.py -> build/lib.linux-i686-2.7
running build
running build_py

You can see under ext3 the newer() function of dep_util.py works correctly and the redundant copy of charley.py to the build directory, when setup.py is run a second time, is skipped. 

Above, with ext4, the mtime comparison was confused.

As I said in the report, not a big problem--but it obviously isn't what was intended so I hoped a problem report would be worthwhile to the distutils developers.

Thanks.
History
Date User Action Args
2011-04-27 15:09:55jsjgrubersetrecipients: + jsjgruber, tarek, eric.araujo
2011-04-27 15:09:55jsjgrubersetmessageid: <1303916995.82.0.476368226289.issue11933@psf.upfronthosting.co.za>
2011-04-27 15:09:53jsjgruberlinkissue11933 messages
2011-04-27 15:09:53jsjgrubercreate