switch to CMake or another build system
Submitted by Adam Dingle
Link to original bug (#717064)
Description
---- 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 (closed): "make install" doesn't install man page (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-08-22 11:24:00 -0700 ----
History
Comment 1
Updated by Adam Dingle almost 3 years ago
- Priority set to High
Comment 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.
Comment 3
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 4
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
Comment 5
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 6
Updated by Adam Dingle over 2 years ago
- Target version set to 0.11
Comment 7
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.11_</strike>
)
Comment 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.
Comment 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
Comment 10
Updated by Adam Dingle over 1 year ago
- Target version set to 0.13
Comment 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.
Comment 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.
Comment 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.
Comment 14
Updated by Eric Gregory over 1 year ago
The Vala wiki lists four build tools.
Of those only Automake, CMake, and Waf appear to be production-ready at this time.
Comment 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.
Comment 16
Updated by Adam Dingle over 1 year ago
Thanks. It's looking more and more likely that we'll switch to CMake, actually.
Comment 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)
Comment 18
Updated by Adam Dingle over 1 year ago
-
Target version deleted (
<strike>
_0.13_</strike>
)
Comment 19
Updated by Joe Bylund 7 months ago
- Category set to build
Comment 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.)
Comment 21
Updated by Adam Dingle 3 months ago
I don't like Autotools either. Here's a vote for Bake:
Comment 22
Updated by Mateusz Loskot 3 months ago
Adam Dingle wrote:
I don't like Autotools either. Here's a vote for Bake:
The idea sounds good to me (as Shotwell user, potential small contributor), but I see a few important issues;
-
"Bake doesn't have a website or written down description of the exact problems it is solving (yet)." (from What is Bake?)
-
[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 ?
Comment 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. :)
Comment 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 :)
Comment 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
Resolution: RESOLVED FIXED