> On May 25, 2016, at 14:57, Alexandre Feblot <[email protected]> wrote: > > 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? >
I’m not entirely sure what you are trying to say. I’m a huge proponent of python 3 and print as a function but I thought at issue here was the risk of shipping scons v3 to users and having everything break. I assumed there was a desire to have current scons users who are happy using scons on their 2.7 system to continue to be able to use scons without editing all their sconstruct files. I am assuming that people can put “from __future_…” in their SConstruct files if they wish to being migrating their scons-usage to modern Python. The Scons test suite would have to do that to let things pass on 2.7 and 3.x. Can we agree that it should be desirable for a current scons user to install v3 without having to make any changes to their code? If we have no choice but to insist on __future__ usage then v3 would be a great time to make that change but I’m pretty sure it’s not needed. — Tim Jenness _______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
