elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

>
> 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