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


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

2014-09-13 Thread Dirk Bächle

Hi William,

On 13.09.2014 00:59, William Blevins wrote:


# No result if tools not available
test.no_result( condition=(test.where_is( 'javac' ) is None) )
test.no_result( condition=(test.where_is( 'jar' ) is None) )
# This test is known to fail as of July 2014; see Tigris issue
1771 and issue 2931.
# Once the underlying issue is corrected, this test should be
re-enabled.
test.skip_test('Skipping derived-source test until issue 1771 is
fixed.\n')


Based on the above code snippet, I don't understand how that is 
possible.  If Java is not installed, then the test should be a no 
result.




and here is what the documentation of TestCmd.no_result() says about this:

def no_result(self = None, condition = 1, function = None, skip = 0):
Causes a test to exit with no valid result.

By default, the no_result() method reports NO RESULT for the test
and exits with a status of 2.  If a condition argument is supplied,
the test fails only if the condition is true.


The point here is that the no_result() method stops the current test 
immediately with a sys.exit(2)...so in the case where one of javac/jar 
can't be found, the skip_test() isn't reached.

That's where the exit code of 2 comes from, I guess.

For an immediate fix, I'd like to suggest simply moving the skip_test() 
line above the no_result()s. Does that sound reasonable?


Regards,

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-13 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 
[…]

My first reaction is: I do not believe this. My second reaction is: of
course I believe it why would it lie to us.

Looking at the waterfall view on the buildbot D has a role in  the
redness of:

Fedora 20 single LDC issue, will reboot to Fedora 20 and investigate.

Debian 7 fails appear to be due to gdmd fails, Gary had flagged this, I
will fix asap. The issue here is that these Debian versions are so old
(!) that they are using a version of the GDC packaging that included
gdmd which is no longer the case in up-to-date versions of GDC.

Debian 6 D tests fails are down to using Python 2.6. The D tests are
written assuming Python 2.7 which is the floor version of Python for
SCons. For other bits of the D tools which had assumed 2.7 someone has
added the truly ugly hack to make it work on 2.6. Yuk :-)

I am guessing the other systems do not have D and now the D tests
correctly do not run.


So the main question is does SCons support Python 2.6 or not?

-- 
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-13 Thread Russel Winder
On Sat, 2014-09-13 at 12:22 +0100, Russel Winder wrote:
[…]
 Fedora 20 single LDC issue, will reboot to Fedora 20 and investigate.

OK, this actually turns out to be quite interesting.

All the tests pass for me as I have dmd installed via a downloaded RPM
and the ldc link phase finds the dmd installed libphobos2.so. So I guess
all these new tests should all check that they can find this file for
the link phase and abandon rather than fail if they cannot.

All this dynamic link library stuff is new fangled as far as D is
concerned and this is actually a package installation issue rather than
a compiler one per se. 

-- 
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-13 Thread William Blevins
I think the short answer is yes, we are trying to support 2.6 in the
future.  I agree with this notion since I would like RHEL6 default python
support, but wouldn't cry if I had to use a custom 2.7 install.  The real
question here is why is there confusion about this, and why does SCons
since 2.3.0 complain about pre-2.7 versus pre-2.6 if we are trying to
support 2.6?  That is a question I cannot answer...  I think that we should
either drop 2.6 support or fix the documentation and development
expectations.  Maybe the confusion with 2.7 is related to python 3 support?
 Once that branch roles out we probably cannot reasonably expect to support
2.6.

V/R,
William

On Sat, Sep 13, 2014 at 7:22 AM, Russel Winder rus...@winder.org.uk 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
 […]

 My first reaction is: I do not believe this. My second reaction is: of
 course I believe it why would it lie to us.

 Looking at the waterfall view on the buildbot D has a role in  the
 redness of:

 Fedora 20 single LDC issue, will reboot to Fedora 20 and investigate.

 Debian 7 fails appear to be due to gdmd fails, Gary had flagged this, I
 will fix asap. The issue here is that these Debian versions are so old
 (!) that they are using a version of the GDC packaging that included
 gdmd which is no longer the case in up-to-date versions of GDC.

 Debian 6 D tests fails are down to using Python 2.6. The D tests are
 written assuming Python 2.7 which is the floor version of Python for
 SCons. For other bits of the D tools which had assumed 2.7 someone has
 added the truly ugly hack to make it work on 2.6. Yuk :-)

 I am guessing the other systems do not have D and now the D tests
 correctly do not run.


 So the main question is does SCons support Python 2.6 or not?

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

 ___
 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-13 Thread Dirk Bächle

On 13.09.2014 17:44, William Blevins wrote:

Dirke,


'tis a week t'early ferrr that. ;)

The top two no_result calls need to work when we add the test for 
real, so we might as well fix them.  I think you answered your own 
question, looks like the skip option needs to be enabled, so the test 
is skipped rather than fails; however, the real question here is, why 
are we running tests on a buildbot without Java installed?  Is 
ignoring a whole language toolchain reasonable?




I would say so, yes. The testsuite can be run by any user who wants to 
check whether his patch introduces a regression. For this, he wants a 
clean run of all tests (passed or skipped) before, and after applying 
his changes. And we don't want to force him having to install Java, 
SWIG, Qt, D,..., and whatnot.
The tests have to cope with uninstalled applications/tools, and this 
gets tested as well...by not installing anything on every Buildbot. As 
long as we have *some* machines with Java in the mix, we should be doing 
fine.


Which leads to the more interesting question: How do we guarantee full 
test coverage, i.e. ensure that each test is properly run at least once 
on a Buildslave?


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-13 Thread Russel Winder
On Sat, 2014-09-13 at 11:50 -0400, William Blevins wrote:
 I think the short answer is yes, we are trying to support 2.6 in the
 future.  I agree with this notion since I would like RHEL6 default python
 support, but wouldn't cry if I had to use a custom 2.7 install.  The real
 question here is why is there confusion about this, and why does SCons
 since 2.3.0 complain about pre-2.7 versus pre-2.6 if we are trying to
 support 2.6?  That is a question I cannot answer...  I think that we should
 either drop 2.6 support or fix the documentation and development
 expectations.  Maybe the confusion with 2.7 is related to python 3 support?
  Once that branch roles out we probably cannot reasonably expect to support
 2.6.

The problem here, as you hint at, is that a decision was made that 2.7
was the base version, but the documentation was inconsistent with the
decision and now people are trying to fix perfectly good 2.7 code to
work with 2.6. The confusion is caused by the confusion :-)

So we need an explicit move, either 2.7 is the base and the
documentation changes or the 2.7 decision is rescinded and a new one to
say 2.6 is the base is made. 

-- 
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-13 Thread William Blevins
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.

V/R,
William

On Sat, Sep 13, 2014 at 2:40 PM, Russel Winder rus...@winder.org.uk wrote:

 On Sat, 2014-09-13 at 11:50 -0400, William Blevins wrote:
  I think the short answer is yes, we are trying to support 2.6 in the
  future.  I agree with this notion since I would like RHEL6 default python
  support, but wouldn't cry if I had to use a custom 2.7 install.  The real
  question here is why is there confusion about this, and why does SCons
  since 2.3.0 complain about pre-2.7 versus pre-2.6 if we are trying to
  support 2.6?  That is a question I cannot answer...  I think that we
 should
  either drop 2.6 support or fix the documentation and development
  expectations.  Maybe the confusion with 2.7 is related to python 3
 support?
   Once that branch roles out we probably cannot reasonably expect to
 support
  2.6.

 The problem here, as you hint at, is that a decision was made that 2.7
 was the base version, but the documentation was inconsistent with the
 decision and now people are trying to fix perfectly good 2.7 code to
 work with 2.6. The confusion is caused by the confusion :-)

 So we need an explicit move, either 2.7 is the base and the
 documentation changes or the 2.7 decision is rescinded and a new one to
 say 2.6 is the base is made.

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

 ___
 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