I should add that I know of internally a few projects that moved from SCons to make/automake/cmake.
The reason was not speed, but understanding and a small functional issue. These projects did not use my Parts extension, but they would have considered it, if they knew about it, even then I believe it would still have failed in many cases as the issue they had was an issue of defining a component builder and sharing it among all the other build components. I don't have this issue in Parts solved yet. I should also not that these cases all had a similar usage pattern. They used SCons as a bunch of env.Execute() statements. They basically did the build during the "read" phase. ( I literally saw 5 different unrelated projects do this same pattern.. not sure why this was picked up) This made SCons look like a bad option. I was able in some of these cases to show them what they wanted to say, but at this point they committed what resource time they had on changing the build system, and needed to meet a schedule. The short of it the move away was based on that someone knew the other system better and could explain it, even if it had it faults. Jason -----Original Message----- From: Scons-dev [mailto:[email protected]] On Behalf Of Kenny, Jason L Sent: Monday, August 25, 2014 3:47 PM To: [email protected]; SCons developer list Subject: Re: [Scons-dev] catching up 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:[email protected]] 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 <[email protected]> wrote: >> On 24.08.2014 21:02, anatoly techtonik wrote: >>> On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner >>> <[email protected]> >>> 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 [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
