Re: [Scons-dev] New keywords for Tigris bugtracker...
On Sun, Apr 27, 2014 at 6:46 AM, Dirk Bächle tshor...@gmx.de wrote: Hi there, I'm currently having a look at the keyword list of our bugtracker at tigris.org. I'd like to add a few keywords such that they can be selected from the global list, but don't seem to have proper admin rights to do that. Can someone jump in and add fortran - Issues awaiting the availability of a Fortran expert. windows - Issues awaiting the availability of a Windows expert. ? That'd be awesome, and many thanks in advance. Remark: I don't intend to go crazy over decorated all issues in the tracker with the proper keywords. And I also understand that it doesn't make sense to invest a lot of work in this area, since we plan to move the tracker to a different place anyway. But for some issues this would really make sense, and provide a better overview. Funny you should mention that. I'm just adding SCons to openhatch ( http://openhatch.org/projects/SCons) per your email last week and my conversation with their leader. I added our tigris tracker, or at least tried to... we'll see if it works. One thing they ask for is how to select bite-sized bugs that would be easy for a newbie to help with; their project setup has a field to select keywords for this. I added Easy. I just added the two keywords you mentioned as well. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] link.py
On Fri, Apr 25, 2014 at 7:54 AM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2014-04-23 at 19:17 +0200, Dirk Bächle wrote: […] I'd like to answer this question, but it's just too cryptic for me. Sorry, but I don't get you...it's not about what the linkers do, but how the Tools set up the variables and command lines for them. Sorry about that. I found a reasonable work around for the problem. However I will work on it a bit more since there is not just one use case as there is with C and C++. Some time ago I was thinking about the C/C++/Fortran link problem (each wants to use the linker its own way) and I thought there might be a nice generalization: a SwitchAction. SwitchAction would be like the ListAction we have today, but it would only execute one of the actions in the list, depending on the value of a predicate (function or build variable). The idea would be to make the main LinkAction into a SwitchAction, and different tools could append their linker action to the list, and (somehow) hook into the predicate to indicate when to use theirs. My hope was to disentangle the linking stuff from the core of SCons with this. If anyone's interested in picking it up, I believe I have a mostly-working implementation of this somewhere. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] scons trunk is broken..
On Sun, Apr 27, 2014 at 1:16 PM, anatoly techtonik techto...@gmail.comwrote: On Sun, Apr 27, 2014 at 8:08 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Sun, Apr 27, 2014 at 12:54 PM, anatoly techtonik techto...@gmail.com wrote: I expect a big problem to be cross-python SConstructs. Do we have any instructions how to write these? I'm not all that concerned about this. Most people will write SConscripts for the python version they're using, whether it's 2 or 3. So those people won't care at all. Most people write just for scons to work. Depending on what this `scons` uses, it may execute SConscript with Python 2 and Python 3, and if SConscript is written for specific Python version, it may fail. Yup. They'll have to fix their SConscripts for the other python version. Not much we can do about that (except as you say, try to give them some guidance). When the 2 users port to 3, they'll have more problems than just their SConscripts to worry about; probably the SConscript changes will be small compared to their other changes. There are many projects that use Python just for SCons build system (or derivative of build system based on SCons). If I understand you correctly, that these people only install Python to run SCons, that'll be OK because they can install whichever version the project recommends. It's my guess that most projects will stay with python2 for at least a couple more years. And of course if people use python3 features in their SConscripts, python2 users won't be able to use them. Sure, there will be some things to keep in mind like unicode string handling and print functions, but I bet a large majority of simple SConscripts will just work or at least a simple 2to3 run will get them close. Did you test that? There is Blender and Wesnoth that can be immediately affected and easy to use. Unfortunately, I can't test them right now. No -- I doubt the python3 branch is even close to ready for that yet. Though early reports of it working or not would be helpful! If we can create instructions like you're talking about, things to do or things to avoid, and put those on the wiki, that would be excellent. We'll probably have to have some experience before we can do that well though. I just want to make sure that when people hit problems, there is already a page to document the problem. It may happen that we will need to introduce shebang header and parse it manually before inclusion to warn users that the SConstruct was designed with another Python version in mind and that they should expect failures. We might end up having to do something like that; let's see how things play out. At this point I'm more concerned with getting it to work at all. :-) But as for having a page of tips on the wiki, definitely let's do that before we release it. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New keywords for Tigris bugtracker...
On 27.04.2014 17:53, Gary Oberbrunner wrote: [...] Funny you should mention that. I'm just adding SCons to openhatch (http://openhatch.org/projects/SCons) per your email last week and my conversation with their leader. I added our tigris tracker, or at least tried to... we'll see if it works. One thing they ask for is how to select bite-sized bugs that would be easy for a newbie to help with; their project setup has a field to select keywords for this. I added Easy. I also had exactly OpenHatch in mind, when asking for Windows/Fortran. ;) We could try to find someone for simply testing old issues about whether they still exist, and possibly developing basic strategies for resolving them (which command-line option is needed for this tool to make things work?). Actually fixing stuff would be a step at the next level for them, so they can slowly progress into the project and are not overwhelmed straight away. I just added the two keywords you mentioned as well. Thanks a lot for that, and also for taking action about OpenHatch already. Very cool! Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons front page
On Sun, 2014-04-27 at 12:00 -0400, Gary Oberbrunner wrote: […] We're making progress, slow but steady. It needs a lot of testing and bug-fixing now. If you can help, please do! OK, I have set myself up to be able to use both SCons default/default and default/python3-port. There is a problem though with the nightmare that is C-style (*) octal constants. I'll see if I can fix this and create a pull request. (*) Ritchie, and Thomson should have fixed C octal constants in the 1970s :-( -- 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 http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] SCons and octal constants
Since the floor version of SCons is now Python 2.7, we should dispense with the horror that is 1970s C-style octal constants and use the 0o form (*). This applies to the default/default branch just as much to the default/python3-port branch (where it is needed for SCons to run at all on Python 3). If making this change is agreed then I guess there needs to be a single changeset alteration proposed to both branches. I am assuming we do this on one branch and then cherry-pick into the other. This would imply doing it for the default/default branch and then cherry-picking into default/python3-port. Thanks. (*) The 0o form works in Python 2.6 as well. -- 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 http://two.pairlist.net/mailman/listinfo/scons-dev
