William Deegan

we can't do that without a deprecation cycle. Best way to do that would be: 1. Add a flag to control it 2. Change default to not free 3. Assuming...

It's possible we've still got users stuck in 32bit world... where it could matter. When this was implemented for some sample build I think it was saving 100mb's of peak...

We'd have to default to current behavior, and then deprecate to off by default or off on 64 bit only.

We've got a wiki page on that :) https://github.com/SCons/scons/wiki/DeprecationCycle But yes as you said, add feature where default is current behavior. announce it's going to change in next release (4.1.0...

> Hmmm, this feature is actually fairly recent... RELEASE 2.3.1. Although I guess that's a decade ago, so not so new. > > Should be easy to put this in,...

I"m not sure we'd need a deprecation cycle for this? It's a undocumented internal function. That said deleting it wholesale could impact users where memory is tight, not sure how...

Hmm.. so this line: https://github.com/SCons/scons/blob/master/SCons/Node/FS.py#L3618 Is the line in question? If so perhaps the solution is to store the modules in `node.rfile().attributes.modules` instead of `node.attributes.modules` ? And/or add a modules...

> Hmmm, not quite sure what the WIndows test failure is. I don't have this setup - it doesn't find gfortran in my case. This _looks_ okay - no errors...

> Attaching the test case for the above (rather than pushing as part of PR, yet), in case someone can spot my errors. > > [fort-variant.tar.gz](https://github.com/SCons/scons/files/13941594/fort-variant.tar.gz) Checked your example in...

I think the only thing we need before merging is a note in FORTRANMODDIR to explain that the path will always be relative to the build root unless it's passed...