Hi Petr, Thanks for taking the time to review the changes.
> I see that you are doing a lot of patching because current Apache is in > different path. So you basically forces all around Apache to build > against proto area only. This is obviously good but on other side it > makes whole change more complicated (which is bad) > The changes to remove the build system's dependency on Apache being already installed on the system are contained in the following files: usr/src/cmd/apache2/Solaris/apr-config.patch usr/src/cmd/apache2/Solaris/apu-config.patch usr/src/cmd/apache2/Solaris/template/apxs.patch usr/src/cmd/php5/patches/php_configure.patch IMO, these changes are not very complicated. The other changes in the patch are mostly related to the implementing 32/64 bit coexistence. > For example patching configure script itself is usually considered as > bad idea. What about patching configure.in? > Since we don't regenerate the configure script (at least for the 2 configure scripts in my patch), how is patching configure different to patching any other source file in the upstream .tar.gz distro? A few other components also directly patch configure. ./hpijs/configure.patch ./diffutils/configure.patch ./a2ps/Patches/configure.patch ./mysql/configure.patch > You have there a lot of patches. It would be good if some of them would > make it to original Apache. Will you try it? apxs would be great but as Yes. I definitely intend to submit all the patches that seem relevant back to the Apache HTTP Server dev community. Demonstrating how a patch fixes a problem in OpenSolaris does make it easier to present the patch/solution to the Apache dev community. > from perfect. This way you wouldn't have to do so many patching and you > could build against installed Apache on system. This means that everyone building SFW will also have to do the same thing i.e. install the new version of Apache in /usr/apache2/2.2/ etc. > > I believe it's better to fix somehow SFW building procedure then patch > programs in gate in the way they become "unreadable". In this particular case, I don't believe the problem is in the SFW building procedure. The Apache modules build rules unnecessarily depend on having Apache installed on the system when they don't have to. Arvind
