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. Raster is approaching those as runtime optional dependencies with manual linking. Currently this is done with libcurl and some other audio stuff. Once needed they will be dlopen()'ed, if they are found the feature is enabled, otherwise it will remain working without that feature. To solve packaging issues my suggestion is that we should document these guys and ask the packages to add some "Recommends: libcurl, libproxy..." instead of "Depends: libcurl, libproxy". -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
