elementary-dev-community team mailing list archive

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

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