On Wed, Dec 5, 2012 at 11:48 AM, Vincent Torri <vincent.to...@gmail.com> wrote: > On Tue, Dec 4, 2012 at 6:54 AM, Carsten Haitzler <ras...@rasterman.com> wrote: >> On Tue, 4 Dec 2012 15:42:01 +1000 David Seikel <onef...@gmail.com> said: >> >>> On Tue, 4 Dec 2012 11:51:18 +0900 Cedric BAIL <cedric.b...@free.fr> >>> wrote: >>> >>> > On Tue, Dec 4, 2012 at 10:17 AM, Gustavo Sverzut Barbieri >>> > <barbi...@profusion.mobi> wrote: >>> > > David, >>> > > >>> > > Your case is extreme and really an onus we shouldn't take. You can >>> > > maintain a patch set or run 1.7. >>> > >>> > I don't think that he is a corner case. As EFL has been designed first >>> > for embedded many developers use it in a constrained environment. My >>> > understanding of this cut out configure option is to first trim them >>> > down as much as we can and then add later the one our developers need. >>> > So basically if he say he doesn't want Ecore_Con for whatever reason >>> > and this become a hard dependency in Ecore_Evas (current state of >>> > affair). Then, we should accept a patch that add --disable-network and >>> > would just disable all internal code of Ecore_Con by a dummy stub. The >>> > rest of EFL will still think that Ecore_Con is there, it will just >>> > always fail to connect or listen to anything. >>> >>> That works for me. B-) >>> >>> Then I can justify spending free time on a patch, instead of doing >>> something very similar for free, but only for the client. I can put it >>> at the end of my TODO and hope some one else does it first. B-) >> >> that's acceptable - but lets trim our hairball of options and ifdefs first... >> and unlike before which was "anything is good as long as its an option"... >> lets >> be very particular about them and just why they are there and how they get >> added. some options you need will nevr be there - but we can make it sane to >> keep a patch for it so you can just have your special "onefang" efl build >> just >> for you and your clients with some minor patches that we dont have to worry >> about. > > what about --disable-efl=[a list of comma separated efl], like > > --disable-list=evas,ecore_directfb,embryo
read: --disable-efl of course > > which disables the evas, ecore_directfb and embryo libs. The > dependency logic is done in configure.ac of course. It will solve > everyone needs, i think > > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel