> > I agree, compiling an existing CMake project is fairly straight forward; > however, adding files or starting a project from scratch has been an > exercise in frustration. >
+1 And Autotools is even more of pain to use and a nightmare to maintain. Moreover, while I would love to have the time to learn CMake, I really > shouldn't have to as it provides no benefit (as far as I can tell) compared > against the "go build" solution. > I used to think so too. "Why do I even need this all CMake mess? My simple 200-line program compiles in just one valac line, right?". Well, it turned out my use cases are not *that* simple. I found myself looking for conditional compilation support (to work OK on systems without Granite), custom VAPI support to backport a necessary fix that I countributed upstream but had to use in an older version. So my "simple" things grew complicated very quickly. I can't see installing to $PATH as a viable soluition since $PATH on elementary OS is "/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" and XDG_DATA_DIRS is "/usr/share/pantheon:/usr/local/share/:/usr/share/" and I can't see a way for the build system to figure out it should actually install to /usr/local/ based on these variables. And I'm not even mentioning cross-distro compatibility, such as reading lib and libexec locations (with libexec possibly being or not being the same as lib), etc. I've seen a "simple" build system in use in elementary - WAF. That was a nightmare comparable to that of autotools or even worse. Any WAF-based build system rapidly disintegrates into a set of custom python scripts substituting for the build system with very little calls to WAF - as the project evolves, you have to override more and more WAF calls and write more and more custom scripts. You end up with something totally unique on your hands, with randomly picked parameters and variables it reads. Given source code with such build system, you have no idea how it works or even how to use it, let alone how to adapt it to a not-really-common configuration, because it follows absolutely no conventions. Hopefully Bake will be a better solution. I haven't tried it yet because I deal mostly with Debian packaging instead of using build systems directly, and there's no handler in debhelper for Bake yet. Since elementary OS used dpkg, we'll need proper debhelper support for Bake in order to use it for our projects. Robert has explicitly stated that Bake is designed to be language-independent, unlike many good but language-specific build systems, but I think he added some kind of automation for GObject nevertheless (Robert likes Vala as much as we do). Bake doesn't have a website yet, only a Launchpad project, and that doesn't happen to mention where to get documentation. Turns out you can view it by obtaining the sources and running "yelp help" there: $ bzr export bake lp:bake; cd bake; yelp help -- Sergey "Shnatsel" Davidoff OS architect @ elementary
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp