Hello,
On 03/19/2018 04:44 PM, William L. Thomson Jr. wrote:
On Mon, 19 Mar 2018 00:56:20 -0400
Cedric Bail <ced...@ddlm.me> wrote:
The CMake build never reached maturity and no further attempt to
improve it is planned. I am actually thinking of removing the build
support from the tree (Not the installed cmake helper to link against
EFL) for next release. Meson is our most likely path forward for a
replacement of our autotools use. It will likely be one release with
both meson and autotools followed by the complete drop of the
autotools support in the next release. No schedule at this point on
when this will happen, but hopefully sometime this year.
I use meson and I really do not understand the craze behind switching
everything to Meson. It has its own issues. It is the most difficult to
deal with under CI. You must install meson and ninja[1]. Then it can
break all of a sudden as meson updates.[2] Which I have to go make such
changes to any using meson like clipboard[3]. Which clipboard is broken
till I require a specific version of meson.
If you find anything that breaks your meson build script, notify the
meson devs, they will fix things super fast, happened to me once for
external projects, and it was fixed within the next release. Same for
other issues.
And btw. after working with meson accross 3 different OSs and multiple
linux distros, i can tell you that using pip to install things is making
life soooo much easier :).
There is already a base cmake build system for EFL. Meson would be
starting from scratch entirely. The speed of meson comes from ninja.
You can use Ninja with CMake. Which CMake + Ninja is just as fast as
Meson + Ninja. Likely spend considerable time with making a meson build
system for EFL. More than fixing cmake IMHO.
There is meson in a feature branch (currently a bit outdated, sorry for
that) that state is much further than cmake, you can build up to evas i
think. Looking at a branch that i need to fix for iOS will even bring
elementary. Comparing the bare speed of meson and cmake is not very
usefull, as most of the time will be spent in ninja. However, meson
takes ~2 min. for configuring complete EFL, cmake (from old numbers
about 2 years ago when i did the cmake stuff) ~4 min. without evas
(which is giant).
Cmake is much more mature than meson, and does not rely on python.
Which python is a PITA. I have more CI builds breaking due to Python
issues lately... CMake is already present in CI and you can just use it
vs messing with installing a build system for CI. Not to mention if a
python update or some other breaks meson, or meson update is to new for
python etc.
Plus cpack, you can easily generate deb and rpm directly from cmake[4]
with trivial effort and almost nothing to maintain. I really like cmake
+ ninja over meson. Meson is ok, but I do not see anything that
impressive to encourage me to use that over cmake. The few I did move
to meson, I will likely move to cmake. Less to maintain.....
There is a module that generates rpm files for meson projects, i think
contributing deb and pkg to it will not be anything that will be
rejected IMO.
General part why i like meson over cmake:
- In cmake you often have the paradigm that one paramter in a function
gives something like a name, the next one the value for the parameter,
typos etc. there are really hard to catch, as most of those functions
are not erroring out on a wrong key. meson simply gives you a warning
"hey, this key is unused"
- Accessing variables... was it ${bla} $bla or bla ?
- meson keeps things very easy by not allowing much, no functions etc.
this is keeping the buildfiles quite straight forward. You dont need to
be a expert in the special efl-cmake use cases, you can just read the
meson stuff and be happy
- pc file printing to the fs without extra files, thats awesome!
- a sane standard set of arguments to pass prefixes libdirs etc.
- the interface for checking dependencies is crazy in cmake, rather a
project comes with the neccessary cmake files, or you can access the
pkgconfig functions by hand, which means you will have magic variables,
that you need to write into your private vars. Without the possibility
of packing everything into a tiny object that you can simply name
"libjpeg" and not "libjpeg_LIBRARIES" "libjpeg_INCLUDEDIR" etc. etc...
Greetings,
bu5hm4n
https://github.com/Obsidian-StudiosInc/entrance/blob/master/.travis.yml#L20
https://travis-ci.org/Obsidian-StudiosInc/entrance/jobs/351531971
https://github.com/Obsidian-StudiosInc/clipboard/blob/master/.travis.yml#L19
https://github.com/Obsidian-StudiosInc/ecrire/blob/master/CMakeLists.txt#L92
------------------------------------------------------------------------------
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
