Re: Change in Install behaviour: no longer makes target file writable after copying, causing build errors
Mats Wichmann <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <[email protected]> |
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.