2013/2/8 Tom Beckmann <[email protected]> > 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 : [email protected] Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
