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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
