>> I would even use APR to build mod_jk: APR of httpd-2.0 >(installed or source) >> otherwise the one given by --with-apr parameter with >configuring mod_jk :)
Ok, we should be carefull with apr, since I've got many problems using it with mod_webapp when creating library libwebapp. I wasn't able to use the libtool generated by Apache 2.0 and could only with the system libtool. The problem is that system libtool (1.3.4) on my Redhat 6.2 couldn't be used to create Apache 2.0 ???????) Nota also that APR stuff is today installed under apache2 subdir in general case but when trying to adhere to FHS, it should be installed /usr/lib/ and /usr/include/apr. APR is just more Apache 2.0 sub lib, it's really a vite new piece of code, used by Apache 2.0 but which will be very usefull for server developpers wanting portable code :) (end of publicity) That's why we add --with-apr-lib and --with-apr-include >I'll go ahead and create an APR directory. To keep things >simple and clear >I'll not touch configure - build.xml will detect if >APR_INCLUDE/apr.h is >present and compile the apr-dependent files. Ok. >The APR code will be entirely optional for now - when we are >comfortable >and everything is tested we can deprecate the current platform-specific >code ( or leave it in - it doesn't hurt and people who have any problem >will have a fallback ) Excellent, we should give a way to user to fall back to OS calls if they could find an APR installed >> The actual makefiles logic is a bit too complex I think >there should be more >> targets to remove the automaticly generated makefiles. > >Is there any reason we don't use GNU make ? This would allow many >simplifications in the build files ( the VPATH is one clear >one, we could >also simplify a lot by using the many functions available in gmake ). A question for people with old make tool, no more a problem for Linux/xxBSD users. What about Solaris, AIX and HP/UX ? >I would also like to have built.properties included in the >Makefile - it >would allow a consistent mechanism of setting preferences ( >paths, etc ) >( i.e. consistent with tomcat and other jakarta projects ). >Not sure how >difficult it would be, but when we switch to APR we'll have no >reason to >use configure - everything is supposed to be portable ! Good >> But is it is still necesary to keep native makefiles when we >have a new _nice_ >> tool? Yes, jkant is a great piece of code but we should keep this functionnalities. Creating native code with java ant is really new and many people will be desoriented. It's >For a while, yes, it's better to have a smooth transition. And we first >need to make sure everyone is comfortable with a new build system. Exact, and have jkant included in jakarta-ant :) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
