2014-09-29 15:43 GMT+01:00 Cedric BAIL <cedric.b...@free.fr>: > On Mon, Sep 29, 2014 at 4:13 PM, Daniel Kolesa <quake...@gmail.com> wrote: > > 2014-09-29 14:23 GMT+01:00 Chris Michael <devilho...@comcast.net>: > >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: > >> > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael < > devilho...@comcast.net> > >> said: > >> >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > >> >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL <cedric.b...@free.fr > > > >> said: > >> >>> > >> >>>> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler < > >> ras...@rasterman.com> > >> >>>> wrote: > >> >>>>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL < > cedric.b...@free.fr> > >> said: > >> >>>>>> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > >> >>>>>> <lucas.de.mar...@gmail.com> wrote: > >> >>>>>>> Em 28/09/2014 08:46, "Graham Gower" <graham.go...@gmail.com> > >> escreveu: > >> >>>>>>>> I've attempted to build using the easy_efl.sh script and > received > >> the > >> >>>>>>>> build error referenced in the subject (full build log follows > >> >>>>>>>> message). > >> >>>>>>>> > >> >>>>>>>> Is there a particular version of udev that is required now, but > >> hasn't > >> >>>>>>>> been put in the autoconf goo? I have udev 182 on a linux distro > >> >>>>>>>> without systemd. > >> >>>>>>> > >> >>>>>>> From > >> >>>>>>> > >> > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > >> >>>>>>> > >> >>>>>>> libudev 199 > >> >>>>>> > >> >>>>>> Question as always how many distribution ship this library and > how > >> >>>>>> many don't. Should we make 199 mandatory or should we just > disable > >> the > >> >>>>>> code that require 199 (I guess it is related to wayland). > >> >>>>> > >> >>>>> since systemd and udev merged... a lot seem to have stopped > updating > >> udev > >> >>>>> at all and may b e on a multi-year-old udev (eg 2011). so our > >> choices are > >> >>>>> to force an upgrade or work on these distros, or we need a way to > >> emulate > >> >>>>> this udev call inside eeze iof udev is older. that means someone > has > >> to > >> >>>>> do the emulation code work there. > >> >>>> > >> >>>> Do we really need to ? We could just disable Wayland support if > udev > >> >>>> is to old, as I think that is the only think that rely on it. The > >> >>>> question is more what about other system than Linux. > >> >>> > >> >>> that makes for a poor eeze api that may or may not work based on a > >> hidden > >> >>> udev version at compile time of eeze. > >> >>> > >> >> > >> >> Well, perhaps for the moment we can detect the udev version and just > >> >> #ifdef the internal eeze code to skip that function call. Fixes the > >> >> build problem while Not breaking code for people that have a sane > udev > >> >> version. Thoughts ?? > >> > > >> > but downside is we have an eeze fn that now is broken for some and not > >> > others... and then when some try wayland things mysteriously fail.. > >> we'll hit > >> > this sooner or later in one form or another. best get it sorted now > >> while fresh. > >> > > >> > >> Ok. Makes sense :) > >> > >> So...what is the general "agreed" plan for sorting this ?? I've seen a > >> couple of thoughts on this thread, but no clear plan/path. I don't mind > >> doing the legwork if we all can agree on a path.... > >> > > > > IMHO best approach would be to create an abstracted library that doesn't > > access libudev or anything directly, but rather provides abstracted > > controls for stuff like backlight, disks etc. - which could potentially > be > > integrated with any OS or backend, including udev, devd, etc.; after > that, > > deprecate Eeze. It would be the cleanest solution, but is also more of a > > long term solution. So for the time being, just ifdef it out and keep a > > ticket open for solution. If there's anything we do *not* need, it's > stupid > > thin wrappers. > > Of course, a better library would be the best solution, sadly no time > nor anyone interested at this stage. I am guessing the one that would > have to do it will be someone that use a BSD all day where those > feature are missing and will start to do it because of that. >
It's not just about BSD, it's also about having a better abstraction on Linux and elsewhere. Thin wrappers suck and are completely useless; might as well use libudev API directly, there's no point in having Eeze. But having a properly abstracted library might provide decent support for different backends, including Linux/udev, Linux/mdev, FreeBSD/devd, whatever OS X uses, etc... and ultimately, make for a better cross platform experience. After all, the purpose of libraries is to abstract away things, not to wrap around them. > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Slashdot TV. Videos for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > D5 ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
