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. -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
