On Tue, 18 Jul 2017 22:01:29 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> On Tue, Jul 18, 2017 at 7: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. > >> > >> 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. > > It is fair because I am not talking of the application layer, but of > the infratructure here, where most of the complexity of portability is > hidden from application. Gstreamer, wayland, libinput, Xorg, systemd > to name a few are migrating. If they can, I am much more confident > that we can, than if you point me to a few application that managed > too. what about windows and osx support? > Feedback from people that migrated to cmake a few years ago and have > now been exposed to meson, is that they would have migrated to meson > if it existed at the time. Some project, like VLC, attempted to > migrate to cmake and the task was much more complex than expected > leading to staying on autotools. sure. this is valuable. and it's the position we find ourselves in now. we get to choose. i really don't know what is better. cmake is definitely more mature. do you have any feedback you can quote or point links to as to why they think meson would be better than cmake? > >> * 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... > > In this case history is what I would call technical debt. cmake wasn't > build for cross compilation please have a look and compare : > https://cmake.org/Wiki/CMake_Cross_Compiling > http://mesonbuild.com/Cross-compilation.html > > I guess cmake as pass maturity point here ;-) More seriously have a > look inside efl/cmake directory to see what I mean by history. Like > ("${s}" STREQUAL "stuff"), seriously, how much better is that compare > to shell ("x$s" = "xstuff") ? Aren't we in 2017, can we just agree > that (s == stuff) is a going to be easier to read ? I am just taking > one example of the syntax of cmake here, but there is plenty to have > fun with. Meson is already there. meh here. can we do subtree builds sanely without triggering full tree rebuilds and so on. thats what matters. it seems the meson stuff for e allows me to build specific binaries and .so's. that's good. i dont know about the context of efl where if you ninja src/lib/eina/libeina.so ... does it go around relinking everything that links to eina? i hope not. if i want that ... i'll rebuild cleanly. meson is fast (the configure stage) and the ninja build is also fast. it is clean enough from what i see. i've figured out how to build specific targets. that's good. > That what I meant when I said cmake had a bad syntax and limited > support for cross compilation. There are serious pain inflicted on the > maintenance that I would prefer to avoid. If I have to learn something > new, meson is nice, does the job and is picked up by a growing number > of our dependencies, cmake is not near that achievement and won't. > > > but i'd like there to be some kind of consistent strategy here. we move to > > the same thing. > > > > 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 disagree with this view completely. It will never be finished and we > won't ever have all our needs addressed. People and most dev will stay > on autotools and won't ever be moving. It needs to be done in two > release. First we do side by side feature equivalent and deprecate > autotools, then for the next release we phase out autotools > completely. Any other approach will lead to failure in my opinion. well of course you do it side by side. you add the meson build files and have it build stuff... then it builds enough to make efl functional. at that point it can be used by default by developers instead of autofoo. we then can fill in the bits that are not ESSENTIAL. once meson (or cmake) could build everything that most devs use/need day to day then it's got to critical mass and things would move fast from there. > > i havent looked yet at the meson branch for e. i have been fixing bugs. > > Please have a look and maybe try converting rage to meson. You will > see it will take you maybe an afternoon and that will be the end of > it. I have converted some of my pet project with module and dep in > that amount of time, I am sure it will be as easy for you. i've now looked. i first don't buy what mike said about his patches making "other build systems easier" it's actually the exact opposite. specializing LESS is better. i've gotten a bit of a flavor of how meson works. it seems decent to me. i want to have this discussion though. what is meson going to be weak on. doing e is one good thing. we have to have a go at doing at least some of efl. something complex with dependencies (ie multiple libraries with one linking to another etc.) actually i'd go for merging .so's at this point... i wonder if we can do custom install rules to add symlinks for binary compat. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
