Re: [Scons-dev] python3-port branch merged to default and then closed

[Russel Winder]

On Mon, 2016-05-23 at 16:39 -0700, Bill Deegan wrote:
> Greetings,
> 
> After a bunch of work py2 is passing all tests on python3-port
> branch.
> So I've merged that to default and closed the python3-port branch.

Thanks for all your work on this, it's great to have a single branch
that is the focus of all effort.

> All further changes/pull requests for py2/3 should be done against
> default.

I will try and get the "futurize -2" stuff going now. I think there are
no remnants of the earlier six based effort that are not consistent
with future. I think the six based effort was well worth it when it was
tried, but now we do not have to support 2.6 removing six and using
future is the right thing to do.

> Currently the bulk of the py3 issues are the following:
> 1) dynamic loading of python modules (Specifically the tool modules)
> doesn't work with the imp module (which is what's currently used) and
> works
> differently under python3. I have some trial work using importlib
> which is
> used when run under python3 (see src/engine/SCons/Tool/__init__.py
> and
> search for importlib)

There may be alternate ways of achieving the goal here rather than just
trying to port. I'll see if I can get into this as soon as I have my
DevoxxUK 2016 and /dev/summer 2016 sessions prepared.

> 2) many tests are failing based on unicode/str differences.  In many
> cases
> this is due to diff'ing done in scons's test infrastructure expecting
> ascii
> string (py2) and not unicode (py3) or byte (py3).

I am fairly sure the futurize -2 phase deal with this.  I suspect that
if we start having to do anything manual about this, we are doing it
wrong. :-)


On Debian Sif with Python 2.7.11+ (I have no idea why the +) I still
get the errors:

Failed the following 7 tests:
test/D/GDC.py
test/D/GDC_Alt.py
test/D/HelloWorld/CompileAndLinkOneStep/sconstest-gdc.py
test/D/HelloWorld/CompileThenLinkTwoSteps/sconstest-gdc.py
test/D/Issues/2939_Ariovistus/sconstest-
correctLinkOptions_gdc.py
test/D/Issues/2940_Ariovistus/sconstest-
correctLinkOptions_gdc.py
test/VariantDir/VariantDir.py

and a whole slew of no results, a few of which I am not convinced
should be no results – I'll investigate further. For the GDC fails
above I think we know the problem causing this: a Debian packaging
problem between the gdc and ldc packages. This is therefore a null
problem for the SCons codebase. The knock-on consequence for SCons
BuildBots and any other CI is that you cannot have both gdc and ldc
installed and Debian (and Ubuntu and Mint?) and expect to get a green.
I have asked the appropriate people to "do something", but…

The VariantDir fail is definitely gfortran related. If the test relies
on the -lg2c flag then perhaps it should test for its presence with the
gfortran being used? If the -lg2c option is not needed then mayhap we
should get rid of it?


|> ./runtest.py test/VariantDir/VariantDir.py
1/1 (100.00%) /usr/bin/python -tt test/VariantDir/VariantDir.py
/home/users/russel/Repositories/Mercurial/SCons/src/script/scons.py returned 2
STDOUT =
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gfortran -o build/var1/b1.o -c -Isrc build/var1/b1.f
buildIt(["build/var1/b2.f"], ["build/var1/b2.in"])
gfortran -o build/var1/b2.o -c -Isrc build/var1/b2.f
gfortran -o build/var1/bar1 build/var1/b1.o -lg2c
scons: building terminated because of errors.

STDERR =
/usr/bin/ld: cannot find -lg2c
collect2: error: ld returned 1 exit status
scons: *** [build/var1/bar1] Error 1

FAILED test of 
/home/users/russel/Repositories/Mercurial/SCons/src/script/scons.py
at line 607 of 
/home/users/russel/Repositories/Mercurial/SCons/QMTest/TestCommon.py (_complete)
from line 710 of 
/home/users/russel/Repositories/Mercurial/SCons/QMTest/TestCommon.py (run)
from line 391 of 
/home/users/russel/Repositories/Mercurial/SCons/QMTest/TestSCons.py (run)
from line 234 of test/VariantDir/VariantDir.py



-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Jason Kenny]

I am unclear on what people are suggesting as fixes to the issue. However I 
believe we tweak the way we “load” the Sconstruct we can control which print 
logic is used when python 2.7 is used. I don’t believe there is any way to 
allow the “classic” python 2.7 print to work in python 3.

 

I think if we can allow user of python 2 and SCons to not have their files 
break, that is a win. When using python 3 the users will need to update the 
SConstruct print statements ( or use some API we might be able to add). With 
this python3 capable drop of SCons I believe we should allow people to migrate 
to the new print() api by injecting a print function when SCons is used in 
python2. Such as function would look something like:

 

# print prototype for python 2.7

def print(*lst,**kw):

msg = list(map(str,lst))

msg = kw.get('sep',' ').join(msg) + kw.get('end','\n')

sys.stdout.write(msg)

 

This should allow users of python 2 to have everything work as expected, given 
them time to move to a python3 like print() function over time. The will be 
able with python2 to have print and print(). This should allow user time to 
migrate SConstructs for a safe move python 3 when they are ready.

 

Still think having an official API will be a good thing long term, however this 
should allow current users to not break. We have to remember that no one is 
using python3 at this time, so expecting Sconstuct to change to work in python 
3 is not unreasonable, given we don’t have API’s in SCons today to prevent 
that. Users still may want to SCons to add Api to make this easier. Such as 
case could happen with files. I know Steve Knight had said a number of times he 
wanted to SCons users to use the node File and Dir to do all file based actions 
for example. If that work had happened it could help as well with current 
builders that will break when moving to python3 because of changes needed in 
the API to load data as expected.

 

Just some thoughts, hope this might help

 

Jason

 

 

From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Bill Deegan
Sent: Wednesday, May 25, 2016 1:08 PM
To: SCons developer list 
Subject: Re: [Scons-dev] no more print statements in SConscripts?

 

Gary,

Yup. that's expected.

Not sure how to handle this gracefully (besides as Jason suggests some 
"official" messaging API for SCons, which also would require time for users to 
adjust to).

Out of curiosity, would 2to3 resolve the issues you ran into?

(In theory it should)

Other issues might bit chmod bitmasks (though not until they run via py3)

-Bill

 

On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner  > wrote:

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

 

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement) in 
SConstructs/SConscripts are now syntax errors. This'll probably be a big change 
for users. Just FYI.


 

-- 

Gary


___
Scons-dev mailing list
Scons-dev@scons.org  
https://pairlist2.pair.net/mailman/listinfo/scons-dev

 

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

Tim, yes, I misread you, thanks for the clarification.
Ok, saved for this time.
--
Alexandre Feblot

> Le 26 mai 2016 à 01:24, Tim Jenness  a écrit :
> 
> 
>> On May 25, 2016, at 16:13, Alexandre Feblot  wrote:
>> 
>> 
>> 
>> Obviously, not introducing any "api break" would be the best, but I don't 
>> see where Tim suggests a solution. Tim wrote about "removing print 
>> statements from his SConscripts", which is exactly the painful case I 
>> described.
>> 
> 
> I don’t think I suggested that. I (thought I) was suggesting that the code in 
> scons that loads the SConscript files should not itself include any print 
> statements so that there would be no need to enable print_function in that 
> file.
> 
> For simple prints in that file you also have the option of doing
> 
> print(some_string)
> 
> which works on both 2.7 and 3.x regardless because in 2.7 those parentheses 
> disappear. It’s only when commas start turning up that you need 
> print_function enabled.
> 
> — 
> Tim Jenness
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 16:13, Alexandre Feblot  wrote:
> 
> 
> 
> Obviously, not introducing any "api break" would be the best, but I don't see 
> where Tim suggests a solution. Tim wrote about "removing print statements 
> from his SConscripts", which is exactly the painful case I described.
> 

I don’t think I suggested that. I (thought I) was suggesting that the code in 
scons that loads the SConscript files should not itself include any print 
statements so that there would be no need to enable print_function in that file.

For simple prints in that file you also have the option of doing

print(some_string)

which works on both 2.7 and 3.x regardless because in 2.7 those parentheses 
disappear. It’s only when commas start turning up that you need print_function 
enabled.

— 
Tim Jenness

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Alexandre,

the code in Default is not currently released.
So if you're running against the development code it's always "Buyer
beware".

It seems likely we will be able to resolve the print_function issue as Tim
has suggested.

Additionally, I don't see the need to install multiple versions of a tool
on a system as onerous.
Especially one which can be installed via virtualenv. (once it completely
is)

-Bill

On Wed, May 25, 2016 at 2:57 PM, Alexandre Feblot 
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?
>
>
> *--*
> Alexandre Feblot
>
> Le 25 mai 2016 à 23:47, Tim Jenness  a écrit :
>
>
> On May 25, 2016, at 14:38, Bill Deegan  wrote:
>
> Tim,
>
> Here's the implementation:
>
> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=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
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 14:57, Alexandre Feblot  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
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

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  a écrit :
> 
>> 
>> On May 25, 2016, at 14:38, Bill Deegan > > wrote:
>> 
>> Tim,
>> 
>> Here's the implementation:
>> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=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 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Thought's on this pull request which cleans up all targets when control-c is pressed..

[Bill Deegan]

https://bitbucket.org/scons/scons/pull-requests/342/cleanup-for-incompletely-built-files/diff

Alexey is concerned about leaving the build in an inconsistant state per
the bug he filed a while back

http://scons.tigris.org/issues/show_bug.cgi?id=2718

One concern I'd have is what about targets marked Precious.

-Bill
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 14:38, Bill Deegan  wrote:
> 
> Tim,
> 
> Here's the implementation:
> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=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
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

Here's the implementation:
https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default=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?

-Bill



On Wed, May 25, 2016 at 11:19 AM, Tim Jenness  wrote:

>
> > On May 25, 2016, at 11:16 , Bill Deegan 
> wrote:
> >
> > I think this is a python global flag isn't it?
> > I don't think you can turn it on and off selectively?
> >
>
> It’s per file. If you add
>
> from __future__ import print_function
>
> at the top of your file that file will have print(). Without it the print
> will be a statement. What you can’t do is change print from a statement to
> a function or vice versa in the middle of a file (so that __future__ import
> must be at the top of the file).
>
> I don’t really know how SConstruct files are imported so it may be that
> there is something about the importing that inherits the print_function
> state of the code doing the reading of the file (are they read and then
> evaled?). If they are read and then the string evaluated that might explain
> the problem. If they are imported with importlib then I’m confused.
>
> —
> Tim Jenness
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

I think this is a python global flag isn't it?
I don't think you can turn it on and off selectively?

-Bill

On Wed, May 25, 2016 at 11:14 AM, Tim Jenness  wrote:

>
> > On May 25, 2016, at 11:12 , Bill Deegan 
> wrote:
> >
> > Tim,
> >
> > The issue then is that we've migrated the SConstructs/SConscripts in the
> test suite to use print() so we can work on getting py3 also working.
> >
>
> I think those tests can have “from __future__ import print_function” added
> to them and the tests would pass.
>
> My worry is releasing scons v3 and having all the python 2.7 users scream.
> If we can just make it so that the importing code for external files does
> not inherit print_function by default then everyone will be happy.
>
> —
> Tim Jenness
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 11:12 , Bill Deegan  wrote:
> 
> Tim,
> 
> The issue then is that we've migrated the SConstructs/SConscripts in the test 
> suite to use print() so we can work on getting py3 also working.
> 

I think those tests can have “from __future__ import print_function” added to 
them and the tests would pass.

My worry is releasing scons v3 and having all the python 2.7 users scream. If 
we can just make it so that the importing code for external files does not 
inherit print_function by default then everyone will be happy.

— 
Tim Jenness


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

The issue then is that we've migrated the SConstructs/SConscripts in the
test suite to use print() so we can work on getting py3 also working.

-Bill

On Wed, May 25, 2016 at 11:11 AM, Tim Jenness  wrote:

> I think “futurize -1 -w SConstruct” would fix everyone’s problems (2.7 is
> the scons minimum version) but it is of course a problem. I don’t know how
> you can tell the scons parser to not enable print_function if it’s running
> in 2.7. Is there a way to disable that __future__ directive for the code
> that is dealing with the SConstruct files?
>
> —
> Tim Jenness
>
> On May 25, 2016, at 11:07 , Bill Deegan  wrote:
>
> Gary,
>
> Yup. that's expected.
> Not sure how to handle this gracefully (besides as Jason suggests some
> "official" messaging API for SCons, which also would require time for users
> to adjust to).
>
> Out of curiosity, would 2to3 resolve the issues you ran into?
> (In theory it should)
>
> Other issues might bit chmod bitmasks (though not until they run via py3)
>
> -Bill
>
> On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner 
> wrote:
>
>> Hi folks; I know I've been out of the loop recently, lots going on. Great
>> work getting the python 3 stuff in!
>>
>> I did just try the default branch (with python2.7 on Windows) and I
>> notice print statements (not the function, just the statement) in
>> SConstructs/SConscripts are now syntax errors. This'll probably be a big
>> change for users. Just FYI.
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Dirk Bächle]

Hi Gary,

On 25.05.2016 14:59, Gary Oberbrunner wrote:

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement)
in SConstructs/SConscripts are now syntax errors. This'll probably be a big 
change for users. Just FYI.



we'd probably have to advise them to use a conversion script like "2to3" on all their SConstructs, right? I'd think this is not too 
much to ask for, if people are really interested in using the Python3 version of SCons...


Regards,

Dirk

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

I think “futurize -1 -w SConstruct” would fix everyone’s problems (2.7 is the 
scons minimum version) but it is of course a problem. I don’t know how you can 
tell the scons parser to not enable print_function if it’s running in 2.7. Is 
there a way to disable that __future__ directive for the code that is dealing 
with the SConstruct files?

— 
Tim Jenness

> On May 25, 2016, at 11:07 , Bill Deegan  wrote:
> 
> Gary,
> 
> Yup. that's expected.
> Not sure how to handle this gracefully (besides as Jason suggests some 
> "official" messaging API for SCons, which also would require time for users 
> to adjust to).
> 
> Out of curiosity, would 2to3 resolve the issues you ran into?
> (In theory it should)
> 
> Other issues might bit chmod bitmasks (though not until they run via py3)
> 
> -Bill
> 
> On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner  > wrote:
> Hi folks; I know I've been out of the loop recently, lots going on. Great 
> work getting the python 3 stuff in!
> 
> I did just try the default branch (with python2.7 on Windows) and I notice 
> print statements (not the function, just the statement) in 
> SConstructs/SConscripts are now syntax errors. This'll probably be a big 
> change for users. Just FYI.
> 
> -- 
> Gary
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Gary,

Yup. that's expected.
Not sure how to handle this gracefully (besides as Jason suggests some
"official" messaging API for SCons, which also would require time for users
to adjust to).

Out of curiosity, would 2to3 resolve the issues you ran into?
(In theory it should)

Other issues might bit chmod bitmasks (though not until they run via py3)

-Bill

On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner 
wrote:

> Hi folks; I know I've been out of the loop recently, lots going on. Great
> work getting the python 3 stuff in!
>
> I did just try the default branch (with python2.7 on Windows) and I notice
> print statements (not the function, just the statement) in
> SConstructs/SConscripts are now syntax errors. This'll probably be a big
> change for users. Just FYI.
>
> --
> Gary
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Jason Kenny]

I think the issue of print was discussed before. I had stated I had some stuff 
in Parts to deal with this, ie a API for outputting data. I recall someone 
saying make it a library SCons could depend on. I have not finished that but do 
have it underway, latest version is in the work of me separating my testing 
code in Parts into a separate module. If interested you can find the code here:

 

https://bitbucket.org/dragon512/reusable-gold-testing-system/src/4c849613824f70a79d47a5cff61d14ac2a495e4b/src/hosts/?at=master
 

 

The code is not 100% done, as such I have not made it a separate pip 
installable module yet.. but it pretty close.

 

I agree that since SCons does not provide an API for outputting information, 
and SCons have not released a injected print() api for people to migrate to 
this will be a big deal for many people using scons at the moment as there 
scripts will break. We might want to consider this before making a new drop. 
This could be a show stopper for a lot of people.

 

Jason

 

From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary 
Oberbrunner
Sent: Wednesday, May 25, 2016 7:59 AM
To: SCons Dev List 
Subject: [Scons-dev] no more print statements in SConscripts?

 

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

 

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement) in 
SConstructs/SConscripts are now syntax errors. This'll probably be a big change 
for users. Just FYI.


 

-- 

Gary

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] no more print statements in SConscripts?

[Gary Oberbrunner]

Hi folks; I know I've been out of the loop recently, lots going on. Great
work getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice
print statements (not the function, just the statement) in
SConstructs/SConscripts are now syntax errors. This'll probably be a big
change for users. Just FYI.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev