[Scons-dev] D tooling doubts

2015-09-23 Thread Russel Winder 
I have now been able to pull in all the new updates which I believe
include changes to the D tooling. I believe there were some potential
issues with this new D tooling. Rather than pollute that old issue/pull
request which is now really done, can we air things here quickly
towards creating a few test cases that I can then add to the
collection? In this way we can either confirm we cannot find a problem,
or if we find a problem then I can try and fix it.

SCons appears to be working unchanged for me with my (rather trivial) D
projects. Which means I cannot observe any problem so far!

-- 
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] D tooling doubts

2015-09-23 Thread Paweł Tomulik 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

W dniu 23.09.2015 o 14:02, Russel Winder pisze:
> I have now been able to pull in all the new updates which I
> believe include changes to the D tooling. I believe there were some
> potential issues with this new D tooling. Rather than pollute that
> old issue/pull request which is now really done, can we air things
> here quickly towards creating a few test cases that I can then add
> to the collection? In this way we can either confirm we cannot find
> a problem, or if we find a problem then I can try and fix it.
> 
> SCons appears to be working unchanged for me with my (rather
> trivial) D projects. Which means I cannot observe any problem so
> far!
> 
> 
> 
> ___ Scons-dev mailing
> list Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> 


1. Do you still need to set 'SHOBJSUFFIX' in SConstruct when using
'dmd' or 'ldc' tool?


2. This doesn't work:

#
env = Environment(tools = ['ldc'])
l = env.SharedLibrary('foo', 'foo.d', SHOBJSUFFIX='.o')
##

AttributeError: 'SConsEnvironment' object has no attribute
'SharedLibrary':

because 'link' tool is still required by D tools (however, they don't
initialize it):

#
env = Environment(tools = ['link', 'ldc'])
l = env.SharedLibrary('foo', 'foo.d', SHOBJSUFFIX='.o')
##


- -- 
Paweł Tomulik, tel. (22) 234 7925
Instytut Techniki Lotniczej i Mechaniki Stosowanej
Politechnika Warszawska
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWAqALAAoJEHZzVvitUXvxMyMP/0QV1P3yIOOMQgAZIpQFeuxF
r25GQAitm92MLsunPEve7TSDE2tstTI6OjcoQrWy4n+6V7F34SS9IxnvglbvmDgh
bR4r72kG6p4YCKmqGiRuccjnLnDdV+c7AhEPFYZ49wGwtmqwsHch5hWNUcw744BF
O9r/uIwrWIAsIUAZBdJx39O70EVToIewI7gU28IodeNNrKOytQhbh/nQdZbGHAH6
K0ATAaNFFQoUlyUBCoGXlE3wQHC1tAFJ8b1t1qQrIQx2XOarm64p4ZzzPsfgqLtX
UbvRaPqsH8N24YpJOfTmu/qBK7Cb9lPIBevCa2mCwBQgHETqwBKuEm3Ninqz2hdL
0OYfJ8QkRRBLmTL9q2qABSD5L7p7NqjKY6tStppi8tLUArtDk/wia657Bp8929mx
DLJqAwv4ObAhHa7dS/5/zLFn53RG5iY7V6eTSl+oEzBToTPSbx/dUtedXUvoBBVn
F85TkhsO3h9ZYkOL91yWao7UOtUa2RRgnohkUaEI+tXuOF7iycWlTs/wleOx7Iwc
swpYIbUtUutDoKGbmlVewtE/Xgzp39sXsCV+Hg6kbdYFzKn7FfUVihpRCnFsaSgI
87ovhTD79ys2yohSrshWdUSp+DBCjZPTUp8qNm4JY/vLAxsfclHKVQutOvlM5LTv
++6oedKaLYJZfQMqmdmS
=yjy5
-END PGP SIGNATURE-
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons 2.4.0 Released

2015-09-23 Thread Russel Winder 
On Tue, 2015-09-22 at 09:13 +0200, Dirk Bächle wrote:
> 
[…]
> 
> I volunteer to weed out some of the old Python 2.x stuff (where x < 7
> ;) ) on a separate bug branch. I have all the scons_testsuite 
> stuff ready (just like for the slots change), in order to show that
> there are no large speed penalties coming with it.
> 
> 
Does this mean we can revert all the 2.6-isms that were introduced
instead of using nice 2.7, 3.3+-isms?

-- 
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] Atlassian, BitBucket, Mercurial

2015-09-23 Thread Russel Winder 
On Wed, 2015-09-23 at 07:08 -0400, Gary Oberbrunner wrote:
> Could be; pretty much _every_ project I can think of is using git
> now.  I
> have to twist my brain around every time I work on SCons. :-)

Which is sad because Git still has so much wrong with it, and Mercurial
has so much going for it. However, the social and commercial pressure
seems inexorable that Git shall be the monopoly.

I think there possible needs to be a new debate about whether to switch
to Git and GitHub. When the decision was made to move from Subversion
on Tigris to Mercurial on BitBucket, I had some issues/doubts, but the
final decision seemed fine and not a problem. However time has moved on
and we are are now in an era where to get any traction as a FOSS
project you appear to have to use GitHub.

OK, I realize it is all "kool kids", "hipsters", and "people who say
awesome evey sentence", but the issue is not one of what is best as a
technology, it is what is best as a way of gaining traction. I
appreciate Mercurial is written in Python (mostly) and Python users
Mercurial, but they have PSF. SCons is just another ancient build
system trying to exist as a FOSS project.

I propose therefore that we switch from Mercurial/BitBucket to
Git/GitHub and that we start a new GitHub issue tracker (even though it
is shite really). Issues from Tigris can be moved over by hand as
needed. This then gives access to Travis, CodeShip, etc. The point here
is not that they are reliable CIs, it is that they are ways of
promoting and marketing the project in the Git-sphere.

Given Buck, Bazel,… SCons needs to do something to make a new presence
or simply drift into the dustbin of history.

-- 
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] Atlassian, BitBucket, Mercurial

2015-09-23 Thread Jason Kenny 
I am not sure about that.
I honestly find Bitbucket UI better than GitHub among other things. I 
personally have moved everything to git. Once microsoft embraced it as part the 
suppported tool chain it just makes it hard to use anything else on the open 
source side in a cross platform way.
At times i think we might want to convert the to GIT from HG on bitbucket. 
However I think bitbucket is a great choice. Honestly most companies that use 
github that i have seen do it as a quick choice. Then they find Bitbucket is 
better from an enterprise point of view, but it is to late at that point. Then 
it seem people then start looking for bug tracking ... Jira seems to be choice. 
For me at the moment it is a mix of GitHub and Atlassian Jira. 
Mercurial is a great system.. but as a company i understand that Atlassian need 
to be responsive to customers and Git is a big push. Now if Git could just fix 
the use of some of the insane usage model people do... so it was not such a 
pain. I guess that is why i like UIs like SourceTree as it help people use it 
in a "good" way that is understandable.
Jason

From: rus...@winder.org.uk
To: scons-dev@scons.org
Date: Wed, 23 Sep 2015 11:57:36 +0100
Subject: [Scons-dev] Atlassian, BitBucket, Mercurial

I see that Atlassian has further demoted the role of Mercurial at
BitBucket, by expunging all reference to Mercurial on the BitBucket
front page –  "BitBucket is the Git Solution…".
 
Clearly Mercurial has no role at BitBucket as far as Atlassian is
concerned. Git users will of course use GitHub, so is this the
beginning of the end for BitBucket?
 
-- 
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] SCons 2.4.0 Released

2015-09-23 Thread Tim Jenness 

> On Sep 23, 2015, at 11:32 , Dirk Bächle  wrote:
> 
> Hi all,
> 
> On 23.09.2015 12:28, Russel Winder wrote:
>> On Tue, 2015-09-22 at 09:13 +0200, Dirk Bächle wrote:
>>> 
>> […]
>>> 
>>> I volunteer to weed out some of the old Python 2.x stuff (where x < 7
>>> ;) ) on a separate bug branch. I have all the scons_testsuite
>>> stuff ready (just like for the slots change), in order to show that
>>> there are no large speed penalties coming with it.
>>> 
>>> 
>> Does this mean we can revert all the 2.6-isms that were introduced
>> instead of using nice 2.7, 3.3+-isms?
>> 
> 
> 
> I'd suggest to continue as follows:
> 
>  - Remove special Python constructs for Python 2.5 and smaller on a bug 
> branch, then merge it
>to tip of "default" as usual.
>  - I'd then like to add another issue on top of this where I do some changes 
> to the core architecture
>(pushing classes around to entangle the dependencies of Node and 
> Taskmaster a little bit), again
>merged to "default".
>  - Then, merge this new tip of "default" to the "python3" branch.
>  - Continue with bugfixing on "default", while on "python3" we can then start 
> to remove 2.6 constructs
>and work on getting the code to be 2.7/3.x compatible at the same time.
> 

Has anyone tried to run futurize with the “-1” option? It’s specifically 
designed to modify 2.x code to the 2.7 compatibility standard without requiring 
any external code (does not need to “import future” but does add “from 
__future__…”). It specifically does not try for python 3 support in that mode.

— 
Tim Jenness


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

Re: [Scons-dev] SCons 2.4.0 Released

2015-09-23 Thread Dirk Bächle 

Hi all,

On 23.09.2015 12:28, Russel Winder wrote:

On Tue, 2015-09-22 at 09:13 +0200, Dirk Bächle wrote:



[…]


I volunteer to weed out some of the old Python 2.x stuff (where x < 7
;) ) on a separate bug branch. I have all the scons_testsuite
stuff ready (just like for the slots change), in order to show that
there are no large speed penalties coming with it.



Does this mean we can revert all the 2.6-isms that were introduced
instead of using nice 2.7, 3.3+-isms?




I'd suggest to continue as follows:

  - Remove special Python constructs for Python 2.5 and smaller on a bug 
branch, then merge it
to tip of "default" as usual.
  - I'd then like to add another issue on top of this where I do some changes 
to the core architecture
(pushing classes around to entangle the dependencies of Node and Taskmaster 
a little bit), again
merged to "default".
  - Then, merge this new tip of "default" to the "python3" branch.
  - Continue with bugfixing on "default", while on "python3" we can then start 
to remove 2.6 constructs
and work on getting the code to be 2.7/3.x compatible at the same time.

Best regards,

Dirk

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

Re: [Scons-dev] Atlassian, BitBucket, Mercurial

2015-09-23 Thread Dirk Bächle 

Hi again,

On 23.09.2015 13:45, Russel Winder wrote:

On Wed, 2015-09-23 at 07:08 -0400, Gary Oberbrunner wrote:

Could be; pretty much _every_ project I can think of is using git
now.  I
have to twist my brain around every time I work on SCons. :-)




here are my 2cents regarding changing our VCS or project hosting:

Let's. Not. Switch.

You ask why? Because I'm happy. I'm so happy that---after a seemingly never-ending series of events, with project managers leaving, 
switching from SVN to hg, migrating our Wiki to Bitbucket, and so on---we've finally reached a state where I can do what I like 
most: coding.


It's tempting to think: yeah, let's just import the current repo into git, push it to Github, and we're good to go again. But I 
count myself to be a member of the core developer team. So, in the case of switching to another VCS I'd feel obliged to work on 
setting up and properly documenting the new workflows in the Wiki. I'd also feel obliged to answer questions from newcomers, or 
people getting confused over the VCS change.

Which is both fine per se, but it would keep me from doing what I like most 
(and am good at, to a certain extent): coding.

But anybody out there has a good chance of convincing me that switching is good for the project overall, by (a priori to the actual 
switch) either:


  - providing a full replacement for the current descriptions of our general development workflow, and about howto creating pull 
requests in particular, for our Wiki and volunteering to answer all upcoming questions about it, or
  - jumping on a large bug or issue (like the python3 branch, for example), setting up his preferred git-hg bridge, working on 
stuff, and wowing me and everybody else with the way he makes impressive progress in a very short time. ;)



Which is sad because Git still has so much wrong with it, and Mercurial
has so much going for it. However, the social and commercial pressure
seems inexorable that Git shall be the monopoly.



I don't feel any pressure in this direction. (see also below)


I think there possible needs to be a new debate about whether to switch
to Git and GitHub.


I don't think so.

When the decision was made to move from Subversion

on Tigris to Mercurial on BitBucket, I had some issues/doubts, but the
final decision seemed fine and not a problem. However time has moved on
and we are are now in an era where to get any traction as a FOSS
project you appear to have to use GitHub.



Can you elaborate a bit on this conclusion? I fail to see the connection between "Project is at Github" and "Project is successful" 
as a direct consequence. How exactly do you get from one to the other?
Isn't it more the fact that, since a lot of projects are at Github (for whatever reasons), there's a high probability that a 
successful project is at Github? Have you checked for the opposite side of the scale? My bet would be that the worst doing projects 
are at Github too...because almost everybody is there!


I always thought that to get any traction and have success, you need to have a good product/project. Why don't we continue working 
on that in the first place?

We have a full roadmap and TODO list, and last time I checked there were 1500+ 
unresolved issues in our Tigris tracker. ;)


OK, I realize it is all "kool kids", "hipsters", and "people who say
awesome evey sentence", but the issue is not one of what is best as a
technology, it is what is best as a way of gaining traction.


See above for my notion of "traction". ;)

I

appreciate Mercurial is written in Python (mostly) and Python users
Mercurial, but they have PSF. SCons is just another ancient build
system trying to exist as a FOSS project.



This feels to me like we should accept getting dictated "from the outside" what to use in our project. I think that SCons as a 
(Python!) project has a good standing and can afford to "flex its muscles" when needed. You say that Mercurial gets left by many 
projects, and we should do the same? Then who's going to stay and ensure that Mercurial doesn't die (sorry, couldn't think of a less 
dramatic word right now)? Isn't this exactly our job, as part of the Python community?



I propose therefore that we switch from Mercurial/BitBucket to
Git/GitHub and that we start a new GitHub issue tracker (even though it
is shite really). Issues from Tigris can be moved over by hand as
needed.


I don't migrate 3000+ issues by hand. Funny thing is, only yesterday I continued working on my converter script for importing all 
Tigris bugs into a Roundup tracker instance. There are just a few minor unresolved problems with it, so if you think a different bug 
tracker "cuts the mustard", please join and help me with it.


This then gives access to Travis, CodeShip, etc. The point here

is not that they are reliable CIs, it is that they are ways of
promoting and marketing the project in the Git-sphere.

Given Buck, Bazel,… SCons needs to do something to make a new presence
or simply drift