[Scons-dev] catching up

[anatoly techtonik]

On Mon, Aug 25, 2014 at 1:52 AM, Dirk Bächle <tshortik at gmx.de> wrote:
> On 24.08.2014 21:02, anatoly techtonik wrote:
>> On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner <garyo at 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.

1. To get clean linear history, which humans can browse without advanced
    graphical tools.
2. To resolve conflicts. Just for example
    https://bitbucket.org/scons/scons/pull-request/155/adds-a-test-case-demonstrating-that-issue/diff#Ltest/SWIG/include-directive.pyT59
2.1 To update CHANGES.txt after other PR did this
3. Addressing review comments
4. Testing PR on top of other fixes
5. Squashing commits
6. Moving stuff to a different branch
7. Finally a reason to know Mercurial better

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

Sorry, it is just a bit of forward thinking. The same stuff that made me mad
when I saw the Docbook toolchain committed. Last time I tried to clone SCons
over SSH it took 20 minutes and I knew it will happen.

As for Lua. Right now there are better systems than SCons in some aspects,
for example http://industriousone.com/premake in Lua which is absent from
http://scons.org/wiki/SconsVsOtherBuildTools and
http://martine.github.io/ninja/ used by Chromium guys, who I believe ditched
SCons at some point even though they've built a Hammer harness on top of it.

The reason why such tools appear is that the old code base becomes too
overcomplicated for new features to add, and I am afraid that people primarily
abandon projects for this reason. I want to be
able to compare architecture of SCons to other tools at any point in time
in build tool evolution, that's why if any low-level optimizations are to be
performed at the cost of simplicity, it would be nice if some thought was put
into how to make them less obtrusive.

I am not using SCons for any project at all, so the time that I can spend on is
not replenished from any 'job reserves' and the only thing I am really
interested
is to get visualization of its internals, just because I am curious.
There is still
a dozen of other ideas, but I don't think they are worthy to be added to
Roadmap or even discussed until production level issues are resolved.

BTW, it would be nice if somebody merge yet another fix for Python 2.6
buildbot:
https://bitbucket.org/scons/scons/pull-request/179/03-fixed-used-imports-that-failed-on/diff

Thanks.