--------- Original Message --------- Subject: Running the test suite on Windows From: "Edward Lu" <[email protected]> Date: 1/21/15 10:05 am To: [email protected]
It appears that the test framework has a bunch of dependencies on unix, e.g. it runs scripts with "#!/usr/bin/...". Running it under cygwin would fix some of those issues, but unfortunately, running under cygwin perl generates unix-like paths in the conf files which a windows-built httpd can't deal with. I'm currently trying to find where it configures those paths so I can hack around the issue. There's also the problem of Windows not having apxs, so a bunch of tests are skipped, but I'm ignoring that one for now. Does anyone have experience/advice/considerations to give on the subject? I'm reasonably confused by your first statement and I'd need a bit of clarification to comment further. You can't mean forward-slashed paths, those are just fine, even by windows itself; just like passing -- before passing file names with leading dashes on unix, you do need to disambiguate the option flag for windows own commands by enclosing such paths in quotes. From a windows command shell prompt, you can observe this with the command dir "c:/windows" Not sure which other scripts you are describing; if specific tests use script to test a feature, e.g. a test to execute a bash shell cgi, then that would simply be "not applicable" to windows (usually). You could introduce further tests that do exercise all of the mechanisms in the win32 cgi functionality (use registry verb associations or a shebang). But if you are describing something else, it must be a more recent test; the entire suite was developed in perl. Compiling under cygwin (or a truly cygwin build with a faux-posix clib) may have some interesting implications. APR implements constructs in a very NT kernel centric way with object handles, so a posix-like cygwin build might become confused at one point or another. I wouldn't expect a mingw build to have such issues since that is a wrapper over the msvcr runtime. If you can track these down, it would be nice to work around the problem cases. Finally, there is an apxs that was never integrated into the httpd project, by our friend Randy Kobes, and Jeff along with the modperl folk finally moved it into subversion (sadly, not httpd's yet :) https://svn.apache.org/repos/asf/perl/apxs/trunk/ Configure and build it on top of an already installed win32 httpd.
