Hi guys, sorry jumping in late, but as the guy that did the migration of WebKit to CMake (for EFL port long ago) and the one that was trying to do cmake-efl, I'm pro meson build for the reasons Cedric said.
While cmake is cleaner than autohell, it's already showing some of its legacy and you end with many "helpers" to do some basic stuff. Meson is cleaning some of that and as they're still "under active development" its more likely (according to their IRC channel) to take some patches and new ideas. As to this thread, I'll start replying to Carsten/Simon: On Tue, Jul 18, 2017 at 11:57 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Wed, 19 Jul 2017 10:10:54 +0930 Simon Lees <sfl...@suse.de> said: > > On 19/07/17 09:53, Cedric BAIL wrote: > > > > > > I also dislike cmake for its syntax and its limited support for cross > > > compilation. Also none of our dependencies have managed to move to cmake, > > > while the one who tried meson managed in no time. Give a look at > > > enlightenment meson files and at efl cmake file to make your own opinion > > > there. My opinion here is that meson is on track to be the replacement of > > > autotools in the open source community. > > > > > > Cedric > > > > As someone who spent 5 years using cmake to cross compile for a range of > > arm and android targets your going to have a tough time convincing me it > > has limited support for cross compiling. Its also worth stating that the > > majority of Qt/KDE based projects are all using cmake and have been > > doing so for a long time so saying that Meson is on track to be the one > > replacement probably isn't fair Until many of the cmake projects start > > migrating as well. > > i agree with you here. That was my impression as well, but the key difference is that meson understands that projects may use their own generated tools during cross compilation. Maybe that was one of their reasons, you know, Glib is also C and they rely on these generators as we do. You can quickly look at http://mesonbuild.com/Cross-compilation.html and see things like: native_exe = executable('mygen', 'mygen.c', native : true) that is, you generate a native build of that tool to then use... edje_cc, eet, eolian... You don't need to force a "-native" build, install, then use EDJE_BIN, EET_BIN... to refer to those. At least for EFL this will be a major win. Is it doable "the old way"? sure, we cross compile EFL with automake and we can with cmake, but it's not as simple. > > * Disclaimer, i'm currently one of the cmake maintainers for openSUSE. I > > also don't mind if we go to meson or cmake as long as its done consistently. > > i also agree. i'm not fussed cmake vs meson. i really don't know which would > ultimately be better. i think cmake probably will have far better and more > mature support for cross compilation, windows, mac etc. than meson would just > due to age and history. but it doesn't mean meson won't get there too... > > but i'd like there to be some kind of consistent strategy here. we move to the > same thing. me too, so as the one previously pushing cmake, I'm all for meson. Actually my guys did a port of Terminology, which will be submitted soon and will help that trend. > i think efl is more easily moved than cedric says. it can be done in stages. > just have the core build work with default + commonly enabled options only. > forget examples, tests, docs etc. ... THEN add in these bit by bit until it is > fully featured. I was experienced with cmake, got help from community and it took us lots of time to do it, and we were very far off in the process. The thing grew big and to avoid breaking stuff is painful... if you go back in cmake patches you'll see that at some point we missed symbols, modules wouldn't load, features would just disappear (ie: mempool defaults)... and most of those errors were silent, they were not build warnings, rather just runtime issues... so needs testing, grepping, etc. which is even worse given that we have other platforms such as windows, mac, ps3... during the process we did some cleanups, like the src/bin split, modules reorganizing and even some uniform flags for feature enable/disable. But that was up to the basics, we'd need to do it for everything. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
