← Back to team overview

elementary-dev-community team mailing list archive

Re: Go-like build tools for Vala


Trivia: there exists an audio podcast of a CMake representative talking
about the project <http://twit.tv/floss111> for an hour or so. Skip to 4:24
for the content.

On Thu, Feb 7, 2013 at 4:47 PM, Sergey "Shnatsel" Davidoff <
sergey@xxxxxxxxxxxxxxxx> wrote:

> 2013/2/8 Tom Beckmann <tomjonabc@xxxxxxxxx>
>> I wrote a script which I think does about what the go build tools would
>> do.
>> http://pastebin.com/hr8TfdPu
>> To see what exactly it should be able to do, check line 30 following :)
>> If you want to use it, it'd be best to copy it to /usr/bin, so you can
>> just run 'ebuild' whenever you want to rebuild something.
>> Some small things like internationalization and installing are still
>> missing, but those are quite easy to add, in case there's interest.
> The problem about this is we now have 3-layered nested generators. This
> thing abstracts/generates CMake which in turn generates makefiles. We have
> three different layers with completely different syntax now.
> The topmost level (this script) covers the most common use cases, but the
> problem is, when you need to diverge a tiny bit, you can't use it anymore
> and have to go to the next level which is completely freaking different.
> And you have to make your way through several hundred lines of generated
> code even though you've never seen it before (maybe even never saw CMake
> before) and have no idea what it does. And that's not even the real thing,
> it's a generator too!
> Another problem with hiding complexity instead of axing it is very well
> illustrated by this script. Let me quote a command the usage notice:
>> clean - Removes build directory, sometimes required to have new packages
>> used correctly
> So you have to remove the build directory and regenerate it once in a
> while. As a newbie, you never know if you should do it after a particular
> change or not. You have to either waste time regenerating it every time, or
> not forget to try and regenerate it if something breaks. In fact, when
> something breaks, you never know on which level the cause is located and
> what did you do wrong (or was it just outdated build directory or some
> other obscure ritual you forgot to perform?).
> When we get to a three-layered system, isn't it the point where we should
> drop it and flatten it all into one level again? Bake seems to do all this
> script does and more while being a flat one-level structure. With it you
> always work with the real thing. There are no startling transitions in the
> learning curve where you should suddenly jump to a whole new level.
> Well, technically there is, it's just much further away so I hope most
> projects won't hit it. Bake is designed to be simple and probably won't be
> able to cover some really advanced use cases, so if your project grows
> really complicated, you'll have to transition to CMake. This is a pretty
> jarring transition, but it exists in the generate-the-cmake solution too
> and after setting up a pretty complex thing in Bake I think you'll have a
> pretty good idea about what your build system does and it will be much
> easier to recreate that in CMake.
> IMO the adoption of Bake depends on how much complexity can it sanely
> cover, i.e. how far away the transition to CMake is. I believe it's farther
> away and less jarring than in the generate-the-cmake approach, but I can't
> see the point of taking time to transition to it or write docs for it if it
> can't cover even a half of our existing projects.
> Either way this is not the right time for such discussion - any drastic
> build system changes should be postponed till Luna+1 cycle.
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp

Cody Garver