[Scons-dev] catching up

[Kenny, Jason L]

Just a project I know of that moved to cmake from scons.

Freeorion: http://www.freeorion.org/index.php/Main_Page 



-----Original Message-----
From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Dirk Bächle
Sent: Monday, August 25, 2014 3:43 PM
To: SCons developer list
Subject: Re: [Scons-dev] catching up

Anatoly,

please find a few comments below.

On 25.08.2014 10:51, anatoly techtonik wrote:
> 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.
Well, unfortunately history isn't always linear when you're working in parallel with several people. I don't mind if a developer locally squashes his commits or uses the MQ extension to reorganize his current bug branch/bookmark for better readability. But once his commits are pushed to his fork at bitbucket (not even the "master"), history should be regarded frozen.
So I wouldn't vote for making "rebase"s mandatory for any pull request...or even go as far as refusing non-fast-forward pushes on the server (current "master").
I just don't think this is the way to go, especially if we're after getting more contributors into the project. We have to be open towards newcomers, for which we should offer a very basic workflow (like we have described now in the Wiki). And experienced developers can feel free to fiddle with their commits while preparing their next pull request.
All together, we're already in a very good state...and for those long-termed dev branches it's just up to a few people to finally detect and embrace the MQ and "rebase" extensions of Mercurial.
> 2. To resolve conflicts. Just for example
>      
> https://bitbucket.org/scons/scons/pull-request/155/adds-a-test-case-de
> monstrating-that-issue/diff#Ltest/SWIG/include-directive.pyT59
A conflict has to get resolved, for "rebase" as well as for a simple "merge". I don't see how a "rebase" is more helpful in this situation.

> 2.1 To update CHANGES.txt after other PR did this 3. Addressing review 
> comments
Once a change was committed, I can only add another commit to amend things. I don't see how a (local) rebase can help here...as written above, I exclude remote rebasing from my considerations.
> 4. Testing PR on top of other fixes
> 5. Squashing commits
> 6. Moving stuff to a different branch
There are other options available, like MQ again, to accomplish these. I still don't see the urgent "need" to have rebasing...sorry.
I guess for every reference you show me, I can come up with a page against git's rebase, like the following:

http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
http://rlc.vlinder.ca/blog/2013/03/flawed-ways-of-working-git-rebase/
   http://jhw.dreamwidth.org/1868.html

, but an URL fight is definitely not what I'm after. For me, it somehow shows that this is a highly opinionated discussion...further meaning that there are no clear facts to decide for one side or the other. So we probably can't lose if we switch (except the efforts for another migration), but we also don't lose a lot if the merge workflows stay as they are now.
> 7. Finally a reason to know Mercurial better
As I said, a highly opinionated discussion... ;)
>>> 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.
Okay, but that's your own perception. Do you know of any projects (names, please) that have ditched SCons because the code base was too complex? When I google for "scons slow", I seem to get more project-related hits than for "scons complicated" or "scons complex".
And for projects like Ardour, Dolfin or Chromium, speed was the main reason to switch.
I'm not trying to toss your concerns aside here, but I would like to take care of the highest prio items first...and highest prio gets somewhat dictated by what most users want, right?

> 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.
The oncoming changes don't affect the architecture and design of SCons at all. So you should be able to visualize whatever parts of SCons you want to analyze, in parallel and completely decoupled from the current development.

Best regards,

Dirk

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev