[Scons-users] Change in Install behaviour: no longer makes target file writable after copying, causing build errors

Mats Wichmann mats at wichmann.us
Sun Apr 11 19:00:27 EDT 2021


On 4/11/21 3:10 PM, Mats Wichmann wrote:
> On 4/11/21 2:02 PM, Thomas Berg wrote:
>> Hi,
>>
>> After upgrading to SCons 4.X, I'm experiencing build failures in the 
>> following use case:
>> - our scons build copies files from a read-only location
>> - whenever the source file changes, and scons copies the updated file, 
>> the build now fails to overwrite the previously copied file, because 
>> it's now read only

> I can't answer at the moment whether this (dropping the chmod) was a 
> change the Python team made for some reason, or whether it was part of 
> our original vendored changes but not marked as such so I missed that.
Okay, slight bit more clarity - I think the vendored copytree() is fine, 
which makes me happier.  It's defined in Tool/install.py, as are the two 
functions that call it - and it's here I made the change that are 
causing your issue: copyFunc() and copyFuncVersionedLib() used to call 
copy2 and then fiddle the destination mode to add stat.S_IWRITE. I 
somehow thought that it was equivalent to do copymode().  It's not 
equivalent. The setting of the write bit seems to have been fully 
intentional.

Now maybe we can spend 30 seconds debating whether an undocumented 
behavior that's in some ways dodgy but in others perfectly natural 
should just be put back, some alternate mechanism to do the same is 
provided, whether we just document things, etc. :)

The shutil module doesn't provide any way to "force" similar to the two 
differing but related options to "cp": "-f/--force" and 
"--remove-destination".  And I don't see a way to really pass something 
like this through the SCons builders, due to amazingly convoluted 
design.  Still looking.


More information about the Scons-users mailing list