Build systems and version control

In GNOME bug 532353, Elijah suggests switching Metacity to waf. Your thoughts on this are requested. I will build this into the test scripts whether or not we go with it in the long term.

Also, no work is getting done (or at least checked in) until the openssh débâcle is over and gone. Would this be a good excuse to move to bzr or git? Advocate please! I like bzr, but mainly because I already use it a lot and I love Python.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

13 thoughts on “Build systems and version control”

  1. waf: no thanks, unless it makes your life much easier too focus more on development
    bzr vs git: git :)

  2. @pclouds: Are you saying that you actually don’t want waf unless it helps us, or that you’re neutral on the matter? And are you saying “no, unless it makes your lives easier to focus more on development” (which it will), or “no, unless it makes focus on development easier, in which case your lives will become better”?

  3. bzr has came a LONG way recently. That being said, git is still faster in most things. For a project the size of metacity, bzr would probably fit perfectly. That being said, git is still faster.

    Laserjock and I got in a discussion about git vs bzr in #ubuntu-kernel and this was his response.

    waf is pretty, and fast. It has a few bugs, but upstream is very interested in helping out in fixing them. Since open source is about choice, why not try out waf and enable it in jhbuild? Let the best build system win!

  4. Another cheer for git! Its fast, and small, and actually makes more sense to me (not like I matter, though).

  5. Hmm, two advocacy wars in one post…

    What about Quagmire? Tom recognizes the nature of the problem in his choice of names ;-)

  6. Why not use mercurial, then?

    It’s fast and powerful as git (expecially if you use mq) and it’s simple and comfrotable as bazaar.

    To be honest, as I use bazaar for my job, I can say first hand that mercurial is even more comfortable than bazaar. :)

    Check the wiki page about distributed SCM for further information.

  7. What exactly can’t we do with autotools that waf can do?

    There should be a really good reason why to spend resources when there is no issue that is being solved.

    Waf is faster (?) and is it’s probably easier to write extensions in python then in m4, but we should wait until waf is production quality, well tested and commonly used before doing this switch.

  8. No circularity :). If it’s really good then new projects will use it and projects who –really need– a ‘better’ autotools system will make a switch. Eventually it should have an established user base.

  9. I don’t see WAF ready for C applications anytime soon, especially in the areas of cross-compilation and coping with all the various (exotic) platforms GNOME does build on succesfully thanks to autotools. I will elaborate on all this soon on desktop-devel-list or somewhere visible (just need to find the time for doing more research for facts and necessities and to write it all up), as it seems to be a premature hype for many GNOME projects, that seems to foil all my plans to make sure most of GNOME is cross-compilable and usable with uclibc until it does get all these features.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *