[Scons-dev] SCons version 2.3.3 is released
SCons version 2.3.3 is now available at the SCons download page, http://www. scons.org/download.php. This is a maintenance release to fix an issue on Windows with MSVC and .def files, and other issues. Here's the changelog: RELEASE 2.3.3 - Sun, 24 Aug 2014 21:08:33 -0400 From Roland Stark: - Fixed false line length calculation in the TempFileMunge class (#2970). From Gary Oberbrunner: - Improve SWIG detection From Russel Winder: - Fix regression on Windows in D language update From Anatoly Techtonik: - Do not fail on EnsureSConsVersion when running from checkout From Kendrick Boyd and Rob Managan: - Fixed the newglossary action to work with VariantDir (LaTeX). From Manuel Francisco Naranjo: - Added a default for the BUILDERS environment variable, to prevent not defined exception on a Clone(). From Andrew Featherstone: - Added description of CheckTypeSize method (#1991). - Fixed handling of CPPDEFINE var in Append() for several list-dict combinations (#2900). From William Blevins: - Added test for Java derived-source dependency tree generation. - Added Copy Action symlink soft-copy support (#2395). - Various contributions to the documentation (UserGuide). As usual, many thanks to all the dedicated people who help keep SCons going! -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
On Sun, Aug 17, 2014 at 5:36 PM, Dirk Bächle tshor...@gmx.de wrote: On 17.08.2014 20:54, Gary Oberbrunner wrote: There's probably not much point in my trying to respond to many of the threads that have been running here in the last couple of weeks; if there are things that should be addressed please bring them up. As for dev priorities, I think we have two big important projects (not counting releasing 2.3.3 which I guess we should do after some further testing?): Python 3 port, and Toolchain. [...] (I know there are lots of other things going on -- I didn't intend the above to be exhaustive.) Making this a little more complete: - patch/bug release 2.3.3? (fix for D tools) - Node class patch (switch to __slots__) - Integration of stubprocess.py - release 2.4? - then, Python3 and Toolchain? OK, step 1's complete. Next up, __slots__ and stubprocess. Both of those will need more testing than usual. We could do a checkpoint release, or just announce on the user list when they're in. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Sun, Aug 17, 2014 at 5:36 PM, Dirk Bächle tshor...@gmx.de wrote: On 17.08.2014 20:54, Gary Oberbrunner wrote: There's probably not much point in my trying to respond to many of the threads that have been running here in the last couple of weeks; if there are things that should be addressed please bring them up. As for dev priorities, I think we have two big important projects (not counting releasing 2.3.3 which I guess we should do after some further testing?): Python 3 port, and Toolchain. [...] (I know there are lots of other things going on -- I didn't intend the above to be exhaustive.) Making this a little more complete: - patch/bug release 2.3.3? (fix for D tools) - Node class patch (switch to __slots__) - Integration of stubprocess.py - release 2.4? - then, Python3 and Toolchain? OK, step 1's complete. Next up, __slots__ and stubprocess. Both of those will need more testing than usual. We could do a checkpoint release, or just announce on the user list when they're in. For testing we need to make buildbots green before making any changes, so that regression testing becomes possible. Merging this: https://bitbucket.org/scons/scons/pull-request/178/taprunner-02-remove-unused-import-that will help fix to this buildbot http://buildbot.scons.org/builders/ubuntu-python-2.6/builds/118/steps/shell/logs/stdio Then I'd like to revisit Mercurial workflow, because we need to clarify how to rebase pull requests. I can also answer other questions about workflow, because Git approach is pretty reasonable, and without some Mercurial candies that are absent in Git it can be hard to stick to it. Our benefit in sticking to Mercurial is to avoid loosing history. I see these two features - stubprocess.py and __slots__ as branches (ideally all feature should be optional, so that you can turn off them, for example for porting code to Lua). But first they need some concise SCons Enhancement page, linked from http://scons.org/wiki/Roadmap so that users can understand what do they need testing. Right now there is no info about stubprocess.by (and other entries should probably by moved to some 'Stale' status). I am not sure we need to do checkpoint releases anymore. It is already possible to run SCons from source, so hg clone and run should be enough to test. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
On Sun, Aug 24, 2014 at 3:02 PM, anatoly techtonik techto...@gmail.com wrote: I am not sure we need to do checkpoint releases anymore. It is already possible to run SCons from source, so hg clone and run should be enough to test. I agree with this. We can probably at least use a bookmark so people can check out something stable to test. I also agree it would be good to get the buildbots green, though in some cases that may be difficult. I'll see what I can do about the symlink one on Windows. I'm learning more about mercurial as I go; I did a lot of rebasing, local cloning, and branch manipulation as part of doing this release and merging trunk (hard not to call it that!) into the python3 branch. So if you have particular questions I can perhaps help. As far as using branches for small features goes, I don't think that is as good an idea in hg as it is in git. Branch names are permanent and immutable, and they take more steps to handle than in git. On the other hand, we do need real branches for big features. I experimented with replacing the python3 branch with a bookmark on the default branch (you can have multiple named heads) but the key thing that made me roll that back was that clueless hg users will do hg update default and that gets the most-recently-modified head on default (even if it's a feature bookmark), rather than the default head (there isn't one). Other than that they might be good, but that seems obnoxious enough to not go that way. I admit I still have in the back of my head the idea to switch to git; I really like git and mercurial feels like a straitjacket to me, although I'm figuring it out more and more. But I want to focus energy on improving scons itself right now; let's leave the workflow pretty much as it is unless changing something would make it much better. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
Hi there, On 24.08.2014 21:02, anatoly techtonik wrote: On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: [...] Then I'd like to revisit Mercurial workflow, because we need to clarify how to rebase pull requests. I would really like to understand why we need a rebase for pull requests in the first place. I see these two features - stubprocess.py and __slots__ as branches (ideally all feature should be optional, so that you can turn off them, for example for porting code to Lua). Lua, what? Where does that suddenly come from? I don't see any porting activities to other languages on the roadmap, and I don't remember any discussions about it either. So why should we give our current development a direction based on imaginary features? Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
