Re: [Scons-dev] Buildbot, Java and D...

2014-09-14 Thread Russel Winder
On Sat, 2014-09-13 at 14:46 -0400, William Blevins wrote:
 Just to clarify.
 
 I am assuming that the python3 baseline requires 2.7+, and the current 2.X
 baseline is still supposed to support 2.6+.  If this is wrong, then I need
 some clarification because someone informed me incorrectly or my memory
 sucks or both.

The decision was taken to make 2.7 the baseline for all of SCons. This
would be helpful in going forward with a Python 2 and Python 3
compatible codebase since lots of Python 3 is being backported to 2.7
anyway.

People then started the issue of 2.6 compliance and a few changes have
been made to the default/tip codebase to support that, but currently
officially as far as I know the base is 2.7 and all the 2.6 fixes are
just making the code ugly.

Confusion is rife on this one now. :-(

-- 
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] Buildbot, Java and D...

2014-09-14 Thread Russel Winder
On Sat, 2014-09-13 at 00:06 +0200, Dirk Bächle wrote:
 Hi there,
 
 I just checked the latest Buildbot runs for my slaves and see
 
test/D/SharedObjects/sconstest-ldc.py
 
 failing under Fedora20. More importantly, the other slaves can't get 

Hummm… how was LDC installed on this machine? Actually I am guessing
using yum which means it is the 2.057 system, which is very old and
doesn't support dynamic libraries. I am using a locally compiled system
which is 2.065 which is the first to have reasonable dynamic library
support.

Thus the test should be switched off for CI usage. The question is
what is the right way of ignoring the test unless the version of LDC is
the right one: I guess run a trial LDC compile and discover the version
number?

-- 
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] Buildbot, Java and D...

2014-09-14 Thread Russel Winder
On Sun, 2014-09-14 at 11:07 +0100, Russel Winder wrote:
[…]
 Hummm… how was LDC installed on this machine? Actually I am guessing
 using yum which means it is the 2.057 system, which is very old and
 doesn't support dynamic libraries. I am using a locally compiled system
 which is 2.065 which is the first to have reasonable dynamic library
 support.

2.063 not 2.057 of course, but…

 Thus the test should be switched off for CI usage. The question is
 what is the right way of ignoring the test unless the version of LDC is
 the right one: I guess run a trial LDC compile and discover the version
 number?

I have installed standard LDC on Debian Sid and on Fedora 20 and all the
test behave as they should without errors as they are. I am at a loss as
how to progress this further.

-- 
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] Buildbot, Java and D...

2014-09-14 Thread Dirk Bächle

Hey guys,

On 14.09.2014 11:56, Russel Winder wrote:

On Sat, 2014-09-13 at 14:46 -0400, William Blevins wrote:

Just to clarify.

I am assuming that the python3 baseline requires 2.7+, and the current 2.X
baseline is still supposed to support 2.6+.  If this is wrong, then I need
some clarification because someone informed me incorrectly or my memory
sucks or both.

The decision was taken to make 2.7 the baseline for all of SCons. This
would be helpful in going forward with a Python 2 and Python 3
compatible codebase since lots of Python 3 is being backported to 2.7
anyway.
let's not fight too much over this, okay? It's clear that we're in a 
transition phase from 2.6 to 2.7. Python 2.7 really *is* the new floor 
for the Python3 branch, so once this gets merged back to default it's 
settled and done.


For the current development on the default branch we don't 
deliberately try to break 2.6 compatibility, as long as possible. This 
is mainly for the convenience of users that try the latest commits of 
the dev version, e.g. if bugs of the released 2.3.3 (which had 2.6 as 
floor) are fixed.
So, if you can develop or fix something by using Python 2.6 lingo *and* 
it also works in Python 2.7+3.x, that's the preferred method at the moment.
If you simply can't do without a Python 2.7 feature, then it's okay to 
introduce the break. But we're not talking about format specifiers here, 
but concepts in the range of slots, metaclasses, functools,..well, 
I hope you get the idea.



People then started the issue of 2.6 compliance and a few changes have
been made to the default/tip codebase to support that, but currently
officially as far as I know the base is 2.7 and all the 2.6 fixes are
just making the code ugly.
Just let the code be ugly. If most things still work for a user under 
2.6, he certainly won't mind. ;)




Confusion is rife on this one now. :-(
I hope my comments above made things a little clearer. To put it 
shortly, the current floors are:


default branch  = 2.6 (as long as possible, before merging in python3 
support)

python3 branch = 2.7

Dirk

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


Re: [Scons-dev] Buildbot, Java and D...

2014-09-14 Thread Dirk Bächle

On 14.09.2014 12:07, Russel Winder wrote:

On Sat, 2014-09-13 at 00:06 +0200, Dirk Bächle wrote:

Hi there,

I just checked the latest Buildbot runs for my slaves and see

test/D/SharedObjects/sconstest-ldc.py

failing under Fedora20. More importantly, the other slaves can't get

Hummm… how was LDC installed on this machine? Actually I am guessing
using yum which means it is the 2.057 system, which is very old and
doesn't support dynamic libraries. I am using a locally compiled system
which is 2.065 which is the first to have reasonable dynamic library
support.
I installed ldc from the Package thingy (GUI), which means having used 
yum in the background, I guess. The exact version currently used is


  ldc-2-57.20140305git6e908ff.fc20 (32-bit)



Thus the test should be switched off for CI usage. The question is
what is the right way of ignoring the test unless the version of LDC is
the right one: I guess run a trial LDC compile and discover the version
number?

I think the question is more like: How should the actual ldc Tool 
behave? What should happen when a user has a version of ldc installed 
in his system, but tries to build a project with dynamic libs involved?


Dirk

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


Re: [Scons-dev] Buildbot, Java and D...

2014-09-14 Thread William Blevins
Configure?

On Sun, Sep 14, 2014 at 7:41 AM, Dirk Bächle tshor...@gmx.de wrote:

 On 14.09.2014 12:07, Russel Winder wrote:

 On Sat, 2014-09-13 at 00:06 +0200, Dirk Bächle wrote:

 Hi there,

 I just checked the latest Buildbot runs for my slaves and see

 test/D/SharedObjects/sconstest-ldc.py

 failing under Fedora20. More importantly, the other slaves can't get

 Hummm… how was LDC installed on this machine? Actually I am guessing
 using yum which means it is the 2.057 system, which is very old and
 doesn't support dynamic libraries. I am using a locally compiled system
 which is 2.065 which is the first to have reasonable dynamic library
 support.

 I installed ldc from the Package thingy (GUI), which means having used
 yum in the background, I guess. The exact version currently used is

   ldc-2-57.20140305git6e908ff.fc20 (32-bit)


  Thus the test should be switched off for CI usage. The question is
 what is the right way of ignoring the test unless the version of LDC is
 the right one: I guess run a trial LDC compile and discover the version
 number?

  I think the question is more like: How should the actual ldc Tool
 behave? What should happen when a user has a version of ldc installed in
 his system, but tries to build a project with dynamic libs involved?


 Dirk

 ___
 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] Buildbot, Java and D...

2014-09-14 Thread Russel Winder
On Sun, 2014-09-14 at 12:39 +0200, Dirk Bächle wrote:
[…]
 let's not fight too much over this, okay? It's clear that we're in a 
 transition phase from 2.6 to 2.7. Python 2.7 really *is* the new floor 
 for the Python3 branch, so once this gets merged back to default it's 
 settled and done.

This wasn't fighting, this was just grumpy grumbling :-)

Given the below I think we probably should say 2.6 is the base version
of Python for default/tip pro tem…

 For the current development on the default branch we don't 
 deliberately try to break 2.6 compatibility, as long as possible. This 
 is mainly for the convenience of users that try the latest commits of 
 the dev version, e.g. if bugs of the released 2.3.3 (which had 2.6 as 
 floor) are fixed.
 So, if you can develop or fix something by using Python 2.6 lingo *and* 
 it also works in Python 2.7+3.x, that's the preferred method at the moment.
 If you simply can't do without a Python 2.7 feature, then it's okay to 
 introduce the break. But we're not talking about format specifiers here, 
 but concepts in the range of slots, metaclasses, functools,..well, 
 I hope you get the idea.

So for me the question is whether to put integers into the {} of format
templates to satisfy 2.6. I think you already did this in one place,
there are others that need doing if 2.6 is the de facto base version in
default/tip. 

  People then started the issue of 2.6 compliance and a few changes have
  been made to the default/tip codebase to support that, but currently
  officially as far as I know the base is 2.7 and all the 2.6 fixes are
  just making the code ugly.
 Just let the code be ugly. If most things still work for a user under 
 2.6, he certainly won't mind. ;)

What about tests and CI, which is where the rest of the problems
relating to my codes are.

  Confusion is rife on this one now. :-(
 I hope my comments above made things a little clearer. To put it 
 shortly, the current floors are:
 
 default branch  = 2.6 (as long as possible, before merging in python3 
 support)
 python3 branch = 2.7

This is actually the first time this has been written down so
explicitly, so it is useful for this email to have been prompted and
written.

In light of this I should change the D tool tests. Hopefully they will
then run on the Debian Python 2.6 somewhat better than now.

-- 
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