So, here we are, we get an incompatibility with existing product build systems based on current scons, and thus, the need to support multiple versions of scons installed on the same machine, so we can keep compiling all old maintenance branches and all old tags of our products without having to fix all of them?
-- Alexandre Feblot > Le 25 mai 2016 à 23:47, Tim Jenness <tjenn...@lsst.org> a écrit : > >> >> On May 25, 2016, at 14:38, Bill Deegan <b...@baddogconsulting.com >> <mailto:b...@baddogconsulting.com>> wrote: >> >> Tim, >> >> Here's the implementation: >> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251 >> >> <https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251> >> >> Basically it exec()'s the SConscript as follows: >> <> exec(compile(_file_.read(), _file_.name, >> 'exec'), >> <> call_stack[-1].globals) >> >> So given that print_function() is already imported from __future__ at that >> point I don't think we can do a per SConscript exclusion? >> > > Right. It compiles a string so print_function is in effect. > > I think what I’d do is ban the use of print in that file so that the > print_function directive is not active. There are only two prints in there so > I’d move those two routines to a different file or provide a utility print > routine from somewhere else that those functions use. > > — > Tim Jenness > > > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org <mailto:Scons-dev@scons.org> > https://pairlist2.pair.net/mailman/listinfo/scons-dev > <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
