checkpoint Blink-side work to use Apache on Windows

Checkpoint Blink-side work to use Apache on Windows

R=ojan@chromium.org, scottmg@chromium.org
BUG=30536

[Dirk Pranke, 2014-02-01 17:10:18]

This patch isn't actually ready for review, but I'm posting it so you can take a
look at it. We need to clean up the language in README.blink to be a little more
explicit about how to reproduce (and update) this set of files, and I expect a
lot of the files in this set aren't actually needed and can be deleted, to
reduce the size of the checkout.

[Dirk Pranke, 2014-02-01 17:14:28]

Argh, ignore the previous comment (it's for the other CL).

This CL isn't ready for review either. I need to re-work the code to support
toggling between lighttpd and apache at runtime so we can land this and keep
testing.

Also, given that we probably don't want to run apache as a service on windows
(need admin privs, so we'll run it as a subprocess instead), we probably want to
restructure the code so that we also run it as a subprocess on mac and linux to
be consistent.

I also need to change the code to save the process id into a pidfile so that if
the code aborts and leaves the httpd running in the background, we can detect
that and clean up on the next run (much of that logic is currently commented
out). 

All of these changes should be straightforward.

There's still a bunch of tests that fail. We need to figure out how to support
CGIs in some form to run the perl and python scripts, and there's at least a few
other issues causing a lot of test to fail.

[Dirk Pranke, 2014-02-04 01:42:14]

Okay, with the latest patch we're starting to see value in this approach; I get
to delete a bunch of baselines where the tests were failing (or at least not
matching the unix results).

I'm down to roughly a dozen failures out of the 2231 tests. The major changes
are:

- I added registry entries locally to indicate how to run perl and python CGI
executables using the ScriptInterpreterSource directive

- I fixed the shebang lines for all of the CGI scripts written in perl to
consistently use -wT ; the above registry hacks don't support differing command
line options (this change can and should probably be landed separately).

I'll now focus on cleaning up the python code, dynamically modifying the
registry as needed, and making it possible to toggle this behind a flag (though,
given the differing baselines, we won't actually expect all of the tests to
produce identical resutls in both configs).

[Dirk Pranke, 2014-02-04 04:43:52]

Okay, patchset #3 has apache code that works and is pretty clean on windows,
code to support both httpd and lighttpd, and the other stuff needed to basically
work. 

The tests should run cleanly under Apache, and you should get a dozen or so
failures under LigHTTPd due to the differing baselines.

The major remaining gotcha is the registry lookup, which I don't know how to
patch on the fly w/o requiring admin privs.

[scottmg, 2014-02-04 04:58:01]

Good stuff, hopefully HKCU\Software\Classes works out.

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
File Tools/Scripts/run-blink-httpd (right):

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
Tools/Scripts/run-blink-httpd:76: try:
idk when this script is used exactly, but why this loop? could it just be a
readline instead?

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/webkitpy/...
File Tools/Scripts/webkitpy/layout_tests/port/win.py (right):

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/webkitpy/...
Tools/Scripts/webkitpy/layout_tests/port/win.py:34: import _winreg
This doesn't exist on cygwin, someone will probably whine.

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/webkitpy/...
Tools/Scripts/webkitpy/layout_tests/port/win.py:91: hkey =
_winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, sub_key)
add some sort of rationalization as to why futzing with the registry is ok. :)

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/webkitpy/...
File Tools/Scripts/webkitpy/layout_tests/servers/apache_http_server.py (right):

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/webkitpy/...
Tools/Scripts/webkitpy/layout_tests/servers/apache_http_server.py:128:
self._start_cmd = start_cmd
so much better!

[Dirk Pranke, 2014-02-04 17:13:15]

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
File Tools/Scripts/run-blink-httpd (right):

https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
Tools/Scripts/run-blink-httpd:76: try:
On 2014/02/04 04:58:01, scottmg wrote:
> idk when this script is used exactly, but why this loop? could it just be a
> readline instead?

It's only used when someone wants to run a server manually to run the tests
interactively. In this situation, the idea is that you run the script in a
window, and ctrl-C it when you're done.

I'm not quite sure what you had in mind w/ readline, but maybe given the above
context it'll make more sense or you can say what you were thinking?

(Previous versions of the script launched the server as a daemon and then could
kill it w/ -k stop. I'm not sure how useful that was, so I'll see if there's
demand for it before landing something here. This script has actually been
pretty broken for a while since it only worked w/ lighttpd, which didn't really
work on mac/linux).

[scottmg, 2014-02-04 17:16:02]

On 2014/02/04 17:13:15, Dirk Pranke wrote:
>
https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
> File Tools/Scripts/run-blink-httpd (right):
> 
>
https://codereview.chromium.org/135583003/diff/100001/Tools/Scripts/run-blink...
> Tools/Scripts/run-blink-httpd:76: try:
> On 2014/02/04 04:58:01, scottmg wrote:
> > idk when this script is used exactly, but why this loop? could it just be a
> > readline instead?
> 
> It's only used when someone wants to run a server manually to run the tests
> interactively. In this situation, the idea is that you run the script in a
> window, and ctrl-C it when you're done.
> 
> I'm not quite sure what you had in mind w/ readline, but maybe given the above
> context it'll make more sense or you can say what you were thinking?

I just meant instead of a moderately busy "while True" loop, it could be just be
"raw_input()".

> 
> (Previous versions of the script launched the server as a daemon and then
could
> kill it w/ -k stop. I'm not sure how useful that was, so I'll see if there's
> demand for it before landing something here. This script has actually been
> pretty broken for a while since it only worked w/ lighttpd, which didn't
really
> work on mac/linux).

[Dirk Pranke, 2014-02-04 17:21:23]

On Tue, Feb 4, 2014 at 9:16 AM, <scottmg@chromium.org> wrote:
>
> I just meant instead of a moderately busy "while True" loop, it could be
> just be
> "raw_input()".


Yeah, then a random keystroke in the window could cause the process to
exit. I'm not sure if that's a good thing, but maybe it is (we could always
log a message like "hit any key to exit").

-- Dirk

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[scottmg, 2014-02-04 17:36:06]

while True: raw_input() if you like. Anyway, I'll stop talking now as this
is clearly not important. :)


On Tue, Feb 4, 2014 at 9:21 AM, Dirk Pranke <dpranke@chromium.org> wrote:

>
>
>
> On Tue, Feb 4, 2014 at 9:16 AM, <scottmg@chromium.org> wrote:
>>
>> I just meant instead of a moderately busy "while True" loop, it could be
>> just be
>> "raw_input()".
>
>
> Yeah, then a random keystroke in the window could cause the process to
> exit. I'm not sure if that's a good thing, but maybe it is (we could always
> log a message like "hit any key to exit").
>
> -- Dirk
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Dirk Pranke, 2014-02-05 02:17:03]

Okay, unfortunately, it looks like running apache in the foreground
(non-daemonized) is not very reliably on unix (looks like it's hard to shut it
down cleanly), so I need to support both modes.

Fortunately, there's not too much code to make that work. I've posted a revised
version with that change to https://codereview.chromium.org/155173003/ .

For some reason, git-cl is being weird about applying my patches; I think it's
getting confused about executable bits and/or binaries . I'll probably need to
break this up into multiple patches to figure out what's going on.

Tomorrow I'll see if I can find some time to test this all on XP.

[Dirk Pranke, 2014-02-26 21:25:00]

closing; this patch is well obsolete.