[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