Re: Change in Install behaviour: no longer makes target file writable after copying, causing build errors
Thomas Berg <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <CABYiQpkwrAC72a9nGg0FPw1M214pD4OsU9uYx7u=w2-yCgs=ew@mail.gmail.com> |
On Mon, 12 Apr 2021 at 01:00, Mats Wichmann <[email protected]> wrote: > 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. :) > > FWIW, we've relied on this behaviour since 2006 (scons-0.96 days), and we would have needed a solution sooner if it hadn't worked for all those years. Other than that, I have no problems seeing both sides of the argument ;) We could add post-actions to fix the files after installation, or write our own install builder I guess. But as long as it doesn't do any harm, it would be convenient if SCons either implements the most useful behaviour or allows an efficient way to configure it. We're already struggling with performance and memory usage, so adding tens of thousands of post-actions probably won't help. Another feature in SCons we value a lot is compatibility: the ability to build a 3 year old revision of the code, without having to install an older scons version, is very convenient. We fix deprecation warnings as soon as possible to maximize this ability. On Mon, 12 Apr 2021 at 01:34, Mats Wichmann <[email protected]> wrote: > See (and comment, if needed) https://github.com/SCons/scons/issues/3927 > > I'll check and possibly add my comments there, instead of reporting another issue for this. Thanks for looking into it! - Thomas _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users