Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread The Rasterman 
On Mon, 19 Mar 2018 18:38:42 +0100 Marcel Hollerbach  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  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 s 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!
> 
>

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread Simon Lees 
On Tuesday, 20 March 2018 02:20:32 ACDT, William L. Thomson Jr. wrote:
> On Mon, 19 Mar 2018 18:55:59 +1030
> Simon Lees  wrote:
>
>> On 19/03/18 15:26, Cedric Bail wrote: ...
>
> That is even messier. Removing cmake build system, but leaving cmake
> artifacts for others using cmake to build stuff against EFL. If you
> have any cmake stuff, why not use it for building EFL?
>
> Sounds like even with meson, some bits of cmake will remain in EFL. I
> do not get the benefit of meson when it will help with maintaining the
> cmake stuff. IMHO would be cleaner to have 1 build system that covers
> it all. Rather than bits for 3rd parties and another for building EFL.

Yes we will have one build system covering all of efl / e internally
eventually, but the set of files required to allow 3rd party apps to use
whichever buildsystem they want whether its autotools, cmake or meson
are simple so as a core system library like efl keeping the build files
to allow 3rd parties to build there efl apps with cmake autotools or
whatever build system they feel like. There is no good real reason to
force 3rd parties to use the same build system e / efl are using.
Especially if they are using efl from binaries rather then building it
themselves.

You can also look at Qt/KDE where Qt / smaller Qt apps tend to use qmake
while almost all kde apps are now using cmake and maybe some are
migrating to meson.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
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

Re: [E-devel] E22 opengl issues

2018-03-19 Thread William L. Thomson Jr. 
On Fri, 16 Mar 2018 13:34:07 -0400
"William L. Thomson Jr."  wrote:
>
> E 22 alpha and beta GTK stops rendering internal content
> https://phab.enlightenment.org/T6144

This remains under software so is not opengl related. Though it happens
considerably less under software, fairly rare. It happens pretty
frequently under opengl/hardware with e22. Never happens with e21,
regardless of EFL versions.

-- 
William L. Thomson Jr.


pgpJZ0s2ooZLS.pgp
Description: OpenPGP digital signature
--
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

Re: [E-devel] EFL packaging on Debian

2018-03-19 Thread Ross Vandegrift 
On Mon, Mar 19, 2018 at 11:21:51AM +0900, Stefan Schmidt wrote:
> I just did run through my monthly packaging status update and was
> pleased to see that efl 1.20.7 has entered Debian unstable a few days
> back.
> 
> I wanted to take this opportunity to thank Ross for his constant work
> on getting this worked out! :-)

Thanks!  Binary packages aren't actually available yet, we're working
around some breakage in dependencies.  Shouldn't be too long.

Ross

--
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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread William L. Thomson Jr. 
On Mon, 19 Mar 2018 18:38:42 +0100
Marcel Hollerbach  wrote:


> 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.

That also means you may always need the latest version of meson for
some feature or another. Making that a requirement for all building
EFL. You may have issues using latest version preventing such.
https://github.com/Obsidian-StudiosInc/entrance/commit/db098127cdedd06a0f359859ccbe5a5df03368f3

Then you get to spend more time fixing things for your nifty build
system.  I have NEVER had any installation or pre-build issues with
cmake. No time spent in setting up cmake for CI, etc. I never had to
require a version of cmake, or avoid any.

> 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 s much easier :).

I am not a fan of python, and that is providing python is installed
etc. You can run into other issues with pip and dependencies...

All failures in last week due to python pip issues...
https://travis-ci.org/Obsidian-StudiosInc/os-xtoo/builds
https://github.com/travis-ci/travis-ci/issues/9349
https://github.com/mrueg/repoman-travis/issues/29

> > 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. 

Mostly looking to make optional support for elogind over systemd, to
any EFL build system.

> 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).
> 
> 
> 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

Only spec files, not a binary
http://mesonbuild.com/RPM-module.html#rpm-module

I recall in IRC the main author wanted to avoid such and recommended
external spec and other stuff to generate rpm and deb. They did not
want to bloat meson or make it like cmake, etc. Wanted to keep it
simple, along with the meson concepts. Thus some contributions like
that maybe rejected.

-- 
William L. Thomson Jr.


pgprIXGnKMSnq.pgp
Description: OpenPGP digital signature
--
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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread Marcel Hollerbach 

Hello,

On 03/19/2018 04:44 PM, William L. Thomson Jr. wrote:

On Mon, 19 Mar 2018 00:56:20 -0400
Cedric Bail  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 s 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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread William L. Thomson Jr. 
On Mon, 19 Mar 2018 15:52:52 +
Stephen Houston  wrote:

> Mason Efl is more complete than cake EFL and will be merged soon.
> It's in a branch in the EFL tree.

Good to know thanks! I still do not see the benefit of meson over
cmake, having used both. Meson seems like a fad to me.

-- 
William L. Thomson Jr.


pgpewB3vvFEM5.pgp
Description: OpenPGP digital signature
--
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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread Stephen Houston 
Mason Efl is more complete than cake EFL and will be merged soon. It's in a
branch in the EFL tree.

On Mon, Mar 19, 2018, 10:45 AM William L. Thomson Jr. <
wlt...@obsidian-studios.com> wrote:

> On Mon, 19 Mar 2018 00:56:20 -0400
> Cedric Bail  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.
>
> 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.
>
> 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.
>
> 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
>
> --
> William L. Thomson Jr.
>
> --
> 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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread William L. Thomson Jr. 
On Mon, 19 Mar 2018 18:55:59 +1030
Simon Lees  wrote:

> On 19/03/18 15:26, Cedric Bail wrote:
> > On March 17, 2018 2:29 PM, William L. Thomson Jr.
> >  wrote:  
> >> I see EFL has a CMakeLists.txt in git. I am curious as to the
> >> current state of that. It seems like it is for past versions,
> >> 1.18.99.57967. Also does not allow build from git.
> >>
> >> Background
> >>
> >> I was looking at updating autotools build for elogind rather than
> >> systemd. Since systemd is required for Wayland. Pretty sure all it
> >> needs is provided by elogind. Systemd is pretty integrated into
> >> autotools and not that familiar with configure.ac. Plus it takes
> >> considerable time to regenerate configure, and run that, etc.
> >>
> >> I believe cmake would be faster there than autotools. Now I know
> >> Meson is the craze. But I actually some what prefer cmake to
> >> meson. CMake can use both autotools or ninja as a generator. Thus
> >> cmake + ninja, is basically just as fast as meson + ninja. I like
> >> some aspects of cmake better, auto-updates po files when locations
> >> change. Though dates can be annoying. Also cpack can easily
> >> generate deb and rpm files with little effort and almost nothing
> >> to maintain.  
> > 
> > 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.
> > 
> > Cedric
> >   
> Not using cmake to build efl, will not mean you cant use cmake for
> building elogind the cmake macro's will continue to be shipped, they
> are hand written and not generated as part of the build (mostly) you
> currently get them installed when building with autotools.

That is even messier. Removing cmake build system, but leaving cmake
artifacts for others using cmake to build stuff against EFL. If you
have any cmake stuff, why not use it for building EFL?

Sounds like even with meson, some bits of cmake will remain in EFL. I
do not get the benefit of meson when it will help with maintaining the
cmake stuff. IMHO would be cleaner to have 1 build system that covers
it all. Rather than bits for 3rd parties and another for building EFL.

-- 
William L. Thomson Jr.


pgpZZP5kfjcTo.pgp
Description: OpenPGP digital signature
--
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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread William L. Thomson Jr. 
On Mon, 19 Mar 2018 00:56:20 -0400
Cedric Bail  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.

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.

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.

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

-- 
William L. Thomson Jr.


pgpAugNr008nO.pgp
Description: OpenPGP digital signature
--
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

Re: [E-devel] State of cmake build system for EFL

2018-03-19 Thread Simon Lees 


On 19/03/18 15:26, Cedric Bail wrote:
> On March 17, 2018 2:29 PM, William L. Thomson Jr. 
>  wrote:
>> I see EFL has a CMakeLists.txt in git. I am curious as to the current
>> state of that. It seems like it is for past versions, 1.18.99.57967.
>> Also does not allow build from git.
>>
>> Background
>>
>> I was looking at updating autotools build for elogind rather than
>> systemd. Since systemd is required for Wayland. Pretty sure all it
>> needs is provided by elogind. Systemd is pretty integrated into
>> autotools and not that familiar with configure.ac. Plus it takes
>> considerable time to regenerate configure, and run that, etc.
>>
>> I believe cmake would be faster there than autotools. Now I know Meson
>> is the craze. But I actually some what prefer cmake to meson. CMake can
>> use both autotools or ninja as a generator. Thus cmake + ninja, is
>> basically just as fast as meson + ninja. I like some aspects of cmake
>> better, auto-updates po files when locations change. Though dates can
>> be annoying. Also cpack can easily generate deb and rpm files with
>> little effort and almost nothing to maintain.
> 
> 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.
> 
> Cedric
> 
Not using cmake to build efl, will not mean you cant use cmake for
building elogind the cmake macro's will continue to be shipped, they are
hand written and not generated as part of the build (mostly) you
currently get them installed when building with autotools.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
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