On 09/22/2016 12:02 AM, Gustavo Sverzut Barbieri wrote:
> On Wed, Sep 21, 2016 at 9:27 AM, Simon Lees <sfl...@suse.de> wrote:
>>
>>
>> On 09/21/2016 12:33 AM, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees <sfl...@suse.de> wrote:
>>>>
>>>>
>>>> On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
>>>>> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>>>>> <barbi...@gmail.com> said:
>>>>>
>>>>>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler <ras...@rasterman.com>
>>>>>> wrote:
>>>>>>> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>>>>>>> <barbi...@gmail.com> said:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Today I did commit support for libproxy in ecore_con's new API,
>>>>>>>> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
>>>>>>>> (implicit from HTTP).
>>>>>>>
>>>>>>> ummm i just am looking now (i have a lot of catching up to do). can you 
>>>>>>> undo
>>>>>>> the changes to configure.ac and make this a dlopen/dlsym approach? well 
>>>>>>> use
>>>>>>> eina_module. look a the old curl eina_module approach. look at what i 
>>>>>>> did in
>>>>>>> ecore_audio too. in fact i need to look over all the efl net code, but 
>>>>>>> you
>>>>>>> want to use emile for ssl stuff and eina_module for curl too there too 
>>>>>>> (i
>>>>>>> haven't looked yet). there are very good reasons to do all of this.
>>>>>>
>>>>>> I've checked what you did for curl, since I use that and need more 
>>>>>> symbols.
>>>>>>
>>>>>> my question and concern are just:
>>>>>>  - not being able to compile without libproxy. If we always detect,
>>>>>> should we remove --enable-libproxy from configure.ac?
>>>>>
>>>>> yes. it moves to runtime not compile-time. several reasons:
>>>>>
>>>>> 1. makes compiling simpler. people dont have to find dependencies and 
>>>>> those
>>>>> -dev/devel pkgs too. if they add libproxy later after building efl 
>>>>> magically
>>>>> the feature works without a rebuild.
>>>>
>>>> No no no, just Never that is about the most evil thing you can do if
>>>> there is no configure check distro's won't know that it should be pulled
>>>> in as a dependency and you will end up with different behavior on
>>>> different machines because one has a completely unrelated package
>>>> installed which also installed the dependency.
>>>>
>>>> Keep the ./configure check, add a --disable-libproxy flag for those that
>>>> don't want to go find it and sure after that dlopen it or whatever. But
>>>> the #1 priority should be making sure that distro packagers don't screw
>>>> it up because after all in a ideal world thats how most people should
>>>> get efl, sure make it easy enough for anyone to compile but don't make
>>>> it easier for distros to shoot there users in the foot by not realising
>>>> theres a extra dependency that probably should be pulled in. Unless of
>>>> course libproxy is not useful on a normal Linux distro and will only
>>>> ever be used in embedded contexts.
>>>
>>> Simon, although I do understand your PoV -- packaging -- Raster is
>>> right and is concerned about runtime impact on non-users.
>>>
>>> If you link to a library, particularly one that has a huge dep graph
>>> like libproxy, you end pulling too much and impacting everyone... even
>>> if that's not used.
>>>
>>
>> So how big in filesize are we talking about? if the distro ships
>> libproxy and isn't slackware it will take care of the dependency graph
>> on its own, if the distro doesn't have it the packager / user can then
>> just pass the --disable flag when building. "Large dependency chain"
>> shouldn't really be an argument distro's handle this fine.
> 
> it's not about disk footprint, rather memory footprint.
> 
> say you use terminology without the URL preview... then why should you
> be linking with libproxy, which in turn will link with glib, mozjs...
> 
> once, if you click an URL, it will dlopen() libproxy and pull those.
> 

Ahh i'm not talking about not dlopening, I just want there to be a
configure check for the library as well as dlopening so that people are
atleast aware they should install it on there system.

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                            Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to