GNOME Bugzilla – Bug 717064
switch to CMake or another build system
Last modified: 2016-07-01 22:30:52 UTC
---- Reported by adam@yorba.org 2010-11-08 16:13:00 -0800 ---- Original Redmine bug id: 2783 Original URL: http://redmine.yorba.org/issues/2783 Searchable id: yorba-bug-2783 Original author: Adam Dingle Original description: It's becoming tedious to maintain our Makefiles and so we'd like to use an automated build system. We'd like to use CMake if possible. Related issues: related to shotwell - Feature #987: "make install" doesn't install man page (Open) ---- Additional Comments From shotwell-maint@gnome.bugs 2013-08-22 11:24:00 -0700 ---- ### History #### #1 Updated by Adam Dingle almost 3 years ago * **Priority** set to _High_ #### #2 Updated by Adam Dingle over 2 years ago * **Target version** set to _0.10_ Our homegrown build system has now become pretty complicated. Maybe we should consider Waf for 0.10. #### #3 Updated by Adam Dingle over 2 years ago * **Target version** deleted (<strike>_0.10_</strike>) #### #4 Updated by Adam Dingle over 2 years ago * **Target version** set to _0.10_ #### #5 Updated by Adam Dingle over 2 years ago * **Target version** deleted (<strike>_0.10_</strike>) #### #6 Updated by Adam Dingle over 2 years ago * **Target version** set to _0.11_ #### #7 Updated by Adam Dingle over 2 years ago * **Target version** deleted (<strike>_0.11_</strike>) #### #8 Updated by Jim Nelson over 2 years ago waf currently can't build Vala projects that have files with the same name in different directories: http://code.google.com/p/waf/issues/detail?id=946 This is currently marked as wontfix because the maintainer believes this is a problem with valac, not waf. Still investigating. #### #9 Updated by Adam Dingle over 1 year ago There's been some controversy about using waf for Debian packages. We should consider this in deciding whether to move to waf: http://lists.debian.org/debian-devel/2012/02/msg00212.html #### #10 Updated by Adam Dingle over 1 year ago * **Target version** set to _0.13_ #### #11 Updated by Luca Falavigna over 1 year ago Please, do not switch to waf! I'm the former maintainer of waf in Debian, and I had to remove the package due to [several problems](http://lists.debian.org /debian-devel/2010/02/msg00714.html). If you need to switch to another build system, please consider to use something saner than waf. #### #12 Updated by Adam Dingle over 1 year ago * **Subject** changed from _use Waf for building_ to _switch to waf or another build system_ Luca, thanks for pointing out these serious reservations about waf. We should look at other build systems before making a decision about this. #### #13 Updated by Jonas Bushart over 1 year ago Maybe CMake. elementary is using this for most of their projects and they are also developing with Vala. I think some of their code could be adapted. #### #14 Updated by Eric Gregory over 1 year ago The Vala wiki [lists four build tools.](https://live.gnome.org/Vala/Tools) Of those only Automake, CMake, and Waf appear to be production-ready at this time. #### #15 Updated by Pim Vullers over 1 year ago In the elementary developers guide (http://tiny.cc/dev-guide-draft) there is an example on how to set up CMake for projects including the additional modules (bundled at https://code.launchpad.net/~xapantu/+junk/cmake-modules) to handle Vala and GSettings within CMake. Hope this helps if you might decide to switch to CMake. #### #16 Updated by Adam Dingle over 1 year ago Thanks. It's looking more and more likely that we'll switch to CMake, actually. #### #17 Updated by Adam Dingle over 1 year ago * **Subject** changed from _switch to waf or another build system_ to _switch to CMake or another build system_ * **Description** updated (diff) #### #18 Updated by Adam Dingle over 1 year ago * **Target version** deleted (<strike>_0.13_</strike>) #### #19 Updated by Joe Bylund 7 months ago * **Category** set to _build_ #### #20 Updated by Mateusz Loskot 3 months ago Here is a good explanation on [Building Vala projects with CMake](http://westh offswelt.de/blog/0043_build_vala_projects_with_cmake_macros.html) Note, it is from 2009 and things might have changed as they usually do in CMake world, regarding new features. On the other hand, as Shotwell is close to GNOME/GTK+, why not to stick to build system default/preferred in those environments? I mean, replace hand- crafted Makefiles with complete GNU Autotools setup. (Disclaimer: I'm not a fan of Autotools at all, but CMake feels like a remote idea for Vala.) #### #21 Updated by Adam Dingle 3 months ago I don't like Autotools either. Here's a vote for Bake: https://launchpad.net/bake #### #22 Updated by Mateusz Loskot 3 months ago Adam Dingle wrote: > I don't like Autotools either. Here's a vote for Bake: > > https://launchpad.net/bake The idea sounds good to me (as Shotwell user, potential small contributor), but I see a few important issues; 1. "Bake doesn't have a website or written down description of the exact problems it is solving (yet)." (from What is Bake?) 2. [Not even a README? It smells to me!](http://tom.preston- werner.com/2010/08/23/readme-driven-development.html) :-) Is it related in any way or inspired by [Bakefile](https://github.com/vslavik/bakefile) ? #### #23 Updated by Adam Dingle 3 months ago No, Bake is not related to Bakefile. It's true that Bake is in a alpha state and may not yet have all the features we would need to migrate Shotwell over. And yes, it desperately needs a Web site and better overview documentation - I've just requested that at https://bugs.launchpad.net/bake/+bug/1215366 Still, I think Bake is quite promising and I've used it successfully with toy projects. It would be very interesting to attempt to port Shotwell to Bake, see what issues arise and work with Robert Ancell (the Bake author) to see if we can fix those so that Shotwell would become the first major program to adopt Bake. If we could do that, surely others would follow, and this would be a significant step toward sending Autotools to oblivion. :) #### #24 Updated by Mateusz Loskot 3 months ago Adam, honestly, it all sounds great to me. In fact, project for porting Shotwell to Bake may become a little guarantee that Bake moves forward and receives more attention. I'm not Vala expert and have too much on my plate now, but I'll be available for testing and bug squashing :) #### #25 Updated by Jim Nelson 3 months ago We use CMake for Geary, which is a significantly less complicated project than Shotwell. I do not believe CMake would somehow lessen the workload we currently face with Shotwell's homebrew solution. I'm down on CMake at the moment. Between Geary and Shotwell, we've tried homebrew, waf, and Cmake, and all have been rather disappointing or frustrating. I like Bake, but I would prefer to move Valencia to it first, then Geary, then consider Shotwell. I've talked with Robert Ancell on and off for a year or more about Bake. I don't want to put words in his mouth, but from our last discussion I don't believe he thinks it's ready for a project like Shotwell. Last year at UDS, a number of Canonical employees -- including package maintainers -- circled me and practically begged for us to move to Autotools. I've spoken with many others inside and outside of GNOME, and all have recommended moving to Autotools. My current belief is that Autotools is like Winston Churchill's democracy: it's the worst form of build system, but better than the others tried from time to time. It's the build system all but endorsed by GNOME and the one that every package maintainer I've spoken with prefers. GNOME produces a number of tools for automating tasks in Autotools we currently have hand-crafted in our make systems or through custom scripts. Whatever distaste we have for Autotools, there is a lot to say in support of using it. If someone was to come forward with a patch moving Shotwell to it, I would gladly give it consideration. --- Bug imported by chaz@yorba.org 2013-11-25 21:48 UTC --- This bug was previously known as _bug_ 2783 at http://redmine.yorba.org/show_bug.cgi?id=2783 Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
https://git.gnome.org/browse/shotwell/log/?h=wip/autotools