On Wed, Jul 19, 2017 at 8:19 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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?
about windows, echart is only built on Windows. I even didn't try a unix build. No problem with Windows and cross compilation as i've already said previously Vincent > >> 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 ------------------------------------------------------------------------------ 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
