On Thu, Jun 23, 2016 at 7:32 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> The patch appears to be as simple as; > ... > Close, not quite. The defect is actually in... if test "$enable_proxy" = "shared"; then proxy_mods_enable=shared elif test "$enable_proxy" = "yes"; then proxy_mods_enable=yes else proxy_mods_enable=most fi We should have never been "forcing" every proxy module within the --enable-proxy=[yes|shared] toggle to build. That is defective. If --enable-proxy is combined with --enable-mods-shared=few why would we build 'all' proxy components? Some --enable-all-proxy flag could have been appropriate, but in a few/none scenario we should never trigger a cluster of modules for electing to build just one. I don't know that such a fix is 'in-scope' of 2.4, the idea is to reduce surprises, so I expect we can't (except on trunk). But we can at least change that behavior to build by-default at the current level (few/most/all/reallyall) with... if test "$enable_proxy" = "yes"; then proxy_mods_enable=$module_selection should produce the desired result, reset all of the proxy_mods to build at the current level (e.g. --enable-mods-shared=few so that all of the proxy modules are attempted but not fatal at level 'few')... however that doesn't cover the 'shared' election. The shared election can be handled if we can agree that an enabled module with a 'shared' dependency is simply promoted to being a shared module should solve that whole headache. In trunk, the combination of 'most' as a fixed option for almost all of the proxy sub-modules (except rarely used methods), with the proxy dependency driving the train, should solve the whole issue. But I won't commit that until we fix the defect in 2.4 so that these don't drift out of sync yet. So I'm still debugging...
