Post by Carsten Haitzler (The Rasterman)Post by Cedric BAILPost by Carsten Haitzler (The Rasterman)Post by Simon LeesPost by Cedric BAILI 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
Post by Carsten Haitzler (The Rasterman)Post by Cedric BAILFeedback 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?
Post by Cedric BAILPost by Carsten Haitzler (The Rasterman)Post by Simon Lees* 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
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.
Post by Cedric BAILThat 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.
Post by Carsten Haitzler (The Rasterman)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.
Post by Cedric BAILPost by Carsten Haitzler (The Rasterman)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.
Post by Cedric BAIL--
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel