On Mon, 13 May 2002, GOMEZ Henri wrote: > We've got a problem here with all the automake stuff added. > There is allready a Makefile.in which will scratch your Makefile > after autoconf.... > > BTW, you're current Makefile seems ready for autoconf/m4 processing > APACHE2_HOME, and the build.properties could be also used. > > So what to do now ? > > - There is a Makefile.apxs which works fine with both Apache 1.3 > and Apache 2.0 > > - There is your Makefile and which could be processed by autoconf > (from Makefile.in to Makefile) > > I'm a little puzzled here since we have now, many way to build > jk2 for apache 2.0 (and 1.3) : > > jkant, Makefile (Apache 2), Makefile.apxs (AP2/AP13), and the automake > stuff. > > What about using only 2 makefiles, one for dynamic (using apxs), one > for static ?
Ok. ( plus ant ) But I'm not sure I understand why do we need automake - if autoconf can generate only the build.properties file ( and probably a .h ). The makefile and ant should read the build.properties to get settings to use ( and that will also allow manual config ). I would like more info on what is autoconf detecting - and make sure we don't duplicate stuff that was detected by apache ( and end up with different settings for apache and jk ). In general, I would like the 2 'styles' work togheter - and the user is able to specify it's explicit preferences in build.properties-style, and autoconf will just guess the rest. It is very common to build the .so on a system and deploy it on another system ( the production server is not a build machine in most cases ), and I want to be sure the user can contol explicitely what options are used. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
