> Or is it safe to just ignore the problem? Any real users out there will > presumably have a ctime that matches the current system time, because > they'll probably have extracted the mod_perl archive only just prior to > building & testing it. > > Otherwise I'm happy for the test to be skipped, so long as there is a > brief comment explaining the reason.
my own thought is this... if we have verified that perl is reporting the correct answer (we've looked at the file on the filesystem and know perl gets it right according to us humans) then the fix really should be in APR - APR is supposed to exist so we can forget about these cross-platform issues and focus on the "real" stuff. as these finfo tests have shown all along, perl seems far better at being cross-platform than APR when it comes to finfo foo. and that being the case, I don't see why we should jump successive hurdles just to prove that APR can't get things straight - this is a straight API we're supporting, without much in the way of intervention (at least last time I checked) so I don't see why we should be saddled with the burned of decyphering whatever quirks APR has in store for us... so, I guess I'd suggest skipping the known bad finfo tests on win32 with a nice, clear message like 'finfo() is known to be very quirky on win32 - use at your own risk' for us developers, it might be nice to run the tests if mod_perl is compiled in maintainer mode so we can keep an eye on things in case APR gets just a bit better... --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
