On 09/22/2016 12:02 AM, Gustavo Sverzut Barbieri wrote: > On Wed, Sep 21, 2016 at 9:27 AM, Simon Lees <[email protected]> wrote: >> >> >> On 09/21/2016 12:33 AM, Gustavo Sverzut Barbieri wrote: >>> On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees <[email protected]> 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 >>>>> <[email protected]> said: >>>>> >>>>>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler <[email protected]> >>>>>> wrote: >>>>>>> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri >>>>>>> <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
