On Thu, Dec 6, 2012 at 1:30 PM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On Thu, Dec 6, 2012 at 10:12 AM, Vincent Torri <[email protected]> > wrote: >> On Thu, Dec 6, 2012 at 12:55 PM, Vincent Torri <[email protected]> >> wrote: >>> On Thu, Dec 6, 2012 at 12:48 PM, Gustavo Sverzut Barbieri >>> <[email protected]> wrote: >>>> On Thursday, December 6, 2012, Enlightenment SVN wrote: >>>> >>>>> Log: >>>>> inotify: revert : i want to keep autotools **modularized**. Instead, use >>>>> in Eio what has been detected in Ecore_File. >>>> >>>> >>>> Damn Vincent, why do you do these things when you don't understand? >>>> >>>> Really, I'm quite disappointed you still don't get how this should work >>>> after this merge, yet you are the one doing the merge. Inotify is a >>>> platform thing and may be used in various modules as already done. There is >>>> no reason, point, sense or intelligence in doing the way it was! >>>> >>>> Apply this commit again and please don't revert things anymore unless you >>>> clearly understand its purpose. >>> >>> funny... >> >> i answer a bit more : your problem is that you have an idea, i have >> another one and you can't stand that someone else is having another >> opinion than your. >> >> I know perfectly what you are trying to do, and i am strongly against that. >> >> With your way of putting everything at the top, you are adding a mess >> that i wanted to avoid. >> >> In addition, that inotify stuff : >> >> 1) is used only in ecore_file and eio (and ecore_file should be >> deprecated). As I said, it is checked in ecore_file, so **USE** the >> result, as I have done with glib. I'm more aware of what is in those >> autotools than you. I know that as i've written them, if you remember >> (/end of sarcasm) > > This is wrong. Not because of cosmetics, but dependency. if you're > doing code, you need a behavior, you create a common function that you > call from both sites. Not call one function expecting one behavior. > > Here you have ecore_file and eio. Both direct users of inotify, it > makes no sense to have eio depend on a test from ecore_file. Even if > that's deprecated and may be removed one day, it's not the case > anytime soon. > > And THAT is the exact point of the single tree merge. You move all > common to a common section. X11, Wayland... will all be checked in a > common section. Same for ipv6, crypto/tls... > > >> 2) is used only in linux, that is, you are adding a useless test for >> all other platforms, so your way is less optimal. Even if you use >> host_os for that, that way is wrong, wrt GNU coding style as it's the >> availability of that feature that must be checked, and not wrt an OS / >> compiler. The only exception is Windows as it's too far from >> UNIX/BSD/POSIX standards. > > In this case I'm open for discussion, we could always check for > inotify.h as we don't fail if it's not there. But indeed I'm just > checking for that with linux to avoid the check when you don't expect > it to exist. It's just a matter of remove want_inotify and always > doing the check. > > I'll come back with the previous commit, change this want_inotify if you wish.
You said in your commit that you fixed code. So split at least your commit into 2 parts : code first (with a bit of autotools if needed) and the remaining part Vincent ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
