On Mon, 19 Mar 2018 18:38:42 +0100 Marcel Hollerbach <m...@bu5hm4n.de> said:
> 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
Actually I've found this to be a mis-feature. I jumped through some hoops to
try and move common template handling into parent meson.build's (see e's
modules as an example), but it'd have been far nicer to just declare functions
to handle each type of module then use those in the module meson.builds.
Instead I ended up with a for loop in the parent iterating over a list of
modules then "sourcing" the child meson.build in the child dir that just sets
variables. Then, based on those vars in the parent, have an if/then/else set of
blocks per type.
The alternative is a lot of copy & paste of the same thing again and again per
module dir. :( I don't think that's cleaner, and it is in the end harder to
maintain if you can't use functions or macros or ways of "collecting repeating
patterns".
> - 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
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
