Hi there, As ecore was merged the biggest bucket is done, then I'm doing a new review and suggestions below:
use_strict="no" AC_ARG_ENABLE([strict], ...) came from evas and shouldn't exist as this is the default and only method. fontconfig and fribidi: would be always enabled, or at least platform dependent. No specific options to disable/enable them. tile-rotate: I'm unsure about this, Raster? sse3: enabled if platform support. There are runtime checks to disable it, as well as env-var. Then there is no problem in always enabling it if compiler supports. (Even if build machine supports, but user machine does not). software-generic: always static, all modules rely on it in a way or another. gl-flavor-gles: Raster, is there any way to detect this? sdl-primitive: Cedric, what's your take on this? At least --with-sdl=yes,no,primitive? simple-x11: Raster, what's your take? Seems that OE can handle this now. Was that the only case? evas buffer engine: always static, no option to disable/remove it. x11: should be --with-x11=none,xcb,x11. Should be valid for evas, ecore_x and ecore_evas gl: any way to do --with-gl=none,gl,gles...? wayland: Etrunko, Antognolli: any way to infer shm x egl from above? loader/saver: always enable eet, jpeg, png and generic. Remove options, these are hard dependencies. (generic if platform supports) dither mask: --with-dither-mask=default,small,line,none thread-safety: always on, remove option. epoll: if platform supports, always on, remove option. g_main_loop implies with_glib == always, then they do not conflict as in the test. (But g_main_loop == yes s&& with_glib = no would conflict). ipv6 = always on if platform supports. Remove option. This is just dependent on libc, that should be the same even if compiling on different machine/build bot. The actual work depends on kernel being enabled with ipv6 and network interfaces, then it's harmless to build even if kernel does not have it. local and abstract sockets: always on if platform supports. Remove option. --with-tls is the same as --with-crypto (from eet). Use the existing with-crypto instead. BTW, Ecore_Con gnutls is already higher than eet, and it provides all the functions Eet checks for availability. We can bump Eet's (with-crypto) to 2.10.2 and remove the checks for gnutls_x509_crt_verify_hash and friends. cares is automatic enable-disable, which is bad. Do strict check. --disable-pool: if platform supports, always on, remove option. --disable-inotify: if platform supports, always on, remove option. --disable-atfile-source: if platform supports, always on, remove option. ecore modules: most should use the same checks as for Evas (see above, --with-x11, --with-gl...). Others should be enabled/disabled strictly, not automagically such as fb, directfb, ... Some remarks: - buffer: always enable. - ews: always enable (small and harmless). - extn: always enable, required by other stuff. - fb: maybe have option to enable tslib? Or tslib is an option on its own? - directfb: I vote for remove and all code. ecore-x-backend: replaced by --with-x11= as above. ecore-x submodules: enable every module. xim, scim, ibus: are they mutually exclusive? --with-imf=xim,scim,ibus? Set or single instance? By fixing the above we should reduce our configure.ac quite a lot and keep it consistent. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
