> wrowe 01/02/25 14:20:25 > > Modified: . Apache.mak libhttpd.mak > modules/aaa mod_auth_anon.mak mod_auth_dbm.mak > mod_auth_digest.mak > modules/cache mod_file_cache.mak > modules/dav/fs mod_dav_fs.mak > modules/dav/main mod_dav.mak > modules/generators mod_info.mak mod_status.mak > modules/mappers mod_rewrite.mak mod_speling.mak > modules/metadata mod_cern_meta.mak mod_expires.mak > mod_headers.mak mod_usertrack.mak > server gen_test_char.mak > . apr.mak libapr.mak > . aprutil.mak libaprutil.mak > srclib/expat-lite expat.mak libexpat.mak > support ab.mak htdigest.mak htpasswd.mak logresolve.mak > Log: > A patch to clean up much bogusity in Win32. Eliminates absolute cd "/..." > references using build/fixwin32mak.pl, and the latest #if APR_HAVE_FOO_H > fixes apparently worked, now that they no longer appear as dependencies > [which had broken the build entirely.] And that's all she wrote - the build builds again from the command line on Win32. I can work on this another hour or two, Greg, if you want to break again for expat-lite. I'm actually not so 'against' leaving it in-place. Here's my thinking. Where are we going to check out apr-iconv for platforms that need it? Some directory buried in the apr-util tree? As in mm? I'm really thinking we want to start bringing some of the -down- into srclib. Sure ... they are the 'apr' srclib's - not necessarily the absolute, latest package. And should we find a very useable package on the machine, then great, ignore them :-) The nice part of the srclib\ solution, is that we simply do this: cd srclib/ cvs checkout apr apr-util apr-xlate apr-mm apr-expat apr-blah apr-blah2 apr-blah3 cd.. Now obviously I'm not about to start checking out apr-mm at all. I don't care. You aren't about to start checking out apr-xlate - if it's already on your machine. This saves everyone some update time, while providing a -single- cvs action to bring down the requisite packages. Thoughts? Bill
