On Thu, May 24, 2018, 06:34 Eric Covener <cove...@gmail.com> wrote: > On Thu, May 24, 2018 at 7:23 AM, Micha Lenk <mi...@lenk.info> wrote: > > Hi Yann, > > > > On 05/24/2018 12:31 PM, Yann Ylavic wrote: > >>> > >>> Well, first things first. Let's first fix trunk to be buildable again > on > >>> build systems that really only link the needed symbols and thus rely on > >>> the > >>> correct library order during linking. > >> > >> > >> I think this is*the* dependency issue, the order in > >> PROGRAM_DEPENDENCIES should make modules depend on core and not the > >> other way around. > > > > > > Yes, sounds reasonable. With the little knowledge about the build system > I > > was just blindly moving library orders around without looking into the > > semantical meaning of these dependencies. > > > >> With this patch, both static and shared builds work for me: > > > > > > Confirmed. Works for me too. > > > > The only thing that I am a bit concerned about is, why is the HTTP ETag > > functionality now part of the core, and not part of the http module > anymore? > > Isn't this somewhat adverse to other efforts to move more code from core > to > > modules? > > Despite the directory structure, this was not part of a "module" in > the httpd/LoadModule sense. I think it's reasonable to pull it "up" > which is simpler then trying to push more stuff down into > modules/http/. >
[Caviet] Note that relocation is a major mmn bump, due to two level namespaces... Which isn't usual apparent on flat namespace architectures such as Linux. >
