On Mon, May 29, 2017 at 12:44:21PM +0200, wm4 wrote: > On Mon, 29 May 2017 12:39:12 +0200 > Diego Biurrun <di...@biurrun.de> wrote: > > On Mon, May 29, 2017 at 12:18:22PM +0200, wm4 wrote: > > > On Mon, 29 May 2017 12:03:26 +0200 > > > Diego Biurrun <di...@biurrun.de> wrote: > > > > On Mon, May 29, 2017 at 11:32:49AM +0200, wm4 wrote: > > > > > On Mon, 29 May 2017 10:56:36 +0200 > > > > > Diego Biurrun <di...@biurrun.de> wrote: > > > > > > --- > > > > > > > > > > > > Log message still not perfect. > > > > > > > > > > > > No longer tries to deduplicate parts of the implementation, just > > > > > > disentangles > > > > > > the protocol declaration. > > > > > > > > > > > > configure | 8 ++------ > > > > > > libavformat/Makefile | 3 +-- > > > > > > libavformat/network.c | 20 -------------------- > > > > > > libavformat/protocols.c | 3 +-- > > > > > > libavformat/tls.c | 39 > > > > > > ++++++++++++++++++++++++++++++--------- > > > > > > libavformat/tls.h | 8 -------- > > > > > > libavformat/tls_gnutls.c | 31 ++++--------------------------- > > > > > > libavformat/tls_openssl.c | 31 ++++--------------------------- > > > > > > libavformat/utils.c | 4 ++++ > > > > > > 9 files changed, 46 insertions(+), 101 deletions(-) > > > > > > > > > > We have a perfectly fine way to modularize protocols (or protocol > > > > > "filters", like TLS, encryption, etc.) - and we're using it in a good > > > > > way. > > > > > > > > Example? > > > > > > Like I said, TLS protocols, encryption, any other form of nested > > > protocols. Nested protocols are the libavformat abstraction to use for > > > this, and TLS fits quite well into it. > > > > > > It works by giving each TLS implementation its own URLProtocol, which > > > the current code does. > > > > > > I don't know what your patch is trying to achieve. > > > > Fix the bug(s) in your splitting of tls.c. tls_protocol no longer exists > > but is referenced in configure. Nested protocols may be a nice abstraction > > but it should not change the way users have to configure a build. There > > should be one way to enable/disable the TLS protocol, not two now and > > possibly four different ones in the future. > > Then why not fix configure instead?
Because configure is not the place to fix this, cleanly or otherwise. I've heard two arguments against my patch so far: 1) The patch adds #ifdefs. 2) .c #includes are not pretty. I fixed 1) in v2 of the patch, 2) is a matter of taste that does not strike me as a particularly convincing argument. I also suspect that the word "disentangle" in the title of the first version of the patch rubbed a few people the wrong way. To quote Martin from memory: "Maybe we do break configure command lines, but we should not." We are discussing such a case here. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
