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

Reply via email to