flame@yamato apache2 % /usr/sbin/apxs2 -q LDFLAGS -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--no-as-needed flame@yamato apache2 % /usr/sbin/apxs2 -q CFLAGS -march=barcelona -O2 -ftracer -pipe -ftree-vectorize -g -ggdb -Wstrict-aliasing=2 -Wno-format-zero-length -Wformat=2 -Wno-error -Wno-pointer-sign This really shouldn't happen.
Diego, as I understand the idea is to build modules with the same CFLAGS/LDFLAGS as the server itself. So this is "by design" and I can't think of good reasons to do this differently. When built, modules are part of apache and ... there is no reason to build them with different settings. It's like there is no measures/need to allow users build parts of the _same_ package with different compiler options.
apxs2 is also used by some third-party Apache modules.
My idea is that this third party modules when built are part of apache and separation of sources does not make it somehow different from modules that come with apache.
The external modules are separate enough from apache that they have their own ebuilds. And, upstream supports this separation somewhat. In this case, Gentoo is not forcibly splitting up a package which is designed to be compiled altogether (which is the case in gstreamer plugins). Since the apache2 core code and external module code are created by different authors, it is conceivable that CFLAGS which work fine with apache2 might not work with modules or vice versa. The apache project and other module writers must have varying coding standards and paradigms. Keeping flags around proliferates stale flag settings. Also, it is frustrating when packages such as apache2 modules just don't obey CFLAGS, CPPFLAGS, LDFLAGS, and other friends (for this reason, portage-multilib has to treat apache specially). It is also more confusing to debug module build failures when this paradigm of apache2 installing its own buildsystem for use by modules is used. Unfortunately, it appears that it is difficult for modules to compile against apache2 on their own. Yet apache2 does support it with apxs -q's INCLUDEDIR and LIBEXECDIR options and the apxs(8) manpage explicitly states that modules may have their own buildsystems and use CPPFLAGS=-I`apxs -q INCLUDEDIR`. But this sort of thing requires working with upstreams...
(In reply to comment #4) > Since the apache2 core code and external module code are created by different > authors, it is conceivable that CFLAGS which work fine with apache2 might not > work with modules or vice versa. If module is very different - just fix module build system to use CFLAGS from environment. My statement here is that apxs2 works as it should - provides CFLAGS apache was build with. > Keeping flags around proliferates stale flag settings. Also, it is frustrating > when packages such as apache2 modules just don't obey CFLAGS, CPPFLAGS, > LDFLAGS, and other friends (for this reason, portage-multilib has to treat > apache specially). That's understandable. But I think fix lays elsewhere. May be provide apxs2-$ABI tools for each ABI apache was built with and then we'll have to fix module's build system anyway. I'm not sure there is perfect solution here but in any case I'd like solution be upstreamable.
