1124906 - Figure out how to run Python code that depends on Windows specific APIs on MSVC cross compiles on Linux

Status: NEW

(Firefox Build System :: General, defect)

Description

[(no longer active)]

For the most part, using the Linux python works great, but we have some Python code (such as cl.py) which uses Windows specific APIs, which means we cannot run it using the normal Linux python installation.

After experimenting with a few approaches, I finally came up with a setup like this.  During configure, when we setup our virtualenv, we create a separate one (called TARGET_PYTHON for the lack of a better name) if that variable is set in the mozconfig (you'd want to set it to something like "wine python").  Then we'd AC_SUBST TARGET_PYTHON as well.  If that variable is not found, TARGET_PYTHON is just defaulted to PYTHON.  For the python scripts that need this environment, we'd switch the $(PYTHON) variable to $(TARGET_PYTHON).

glandium, is this an acceptable approach?

(Note that this can potentially make bug 1123017 and bug 1122930 unnecessary.)

Comment 1

[Mike Hommey [:glandium]]

Why not just build from the msys shell? There are many other things that assume that the host and target OS are the same for windows builds.

Comment 2

[(no longer active)]

(In reply to Mike Hommey [:glandium] from comment #1)
> Why not just build from the msys shell?

Because it's *too* slow.  As in, many times x Windows slow.

> There are many other things that
> assume that the host and target OS are the same for windows builds.

We should fix those issues.  Do you know of others off hand?

Comment 3

[Gregory Szorc [:gps]]

Related to this, I've always wanted to have a universal compiler wrapper script that did things like measure system resource usage (via psutil.Process) and parsed compiler warnings. Currently, compiler warning parsing is performed over make's output. And that is prone to issues because of interleaved output and relevant output being sometimes hundreds of lines above where make eventually terminates. Something to consider.

Comment 4

[(no longer active)]

(In reply to Gregory Szorc [:gps] from comment #3)
> Related to this, I've always wanted to have a universal compiler wrapper
> script that did things like measure system resource usage (via
> psutil.Process) and parsed compiler warnings. Currently, compiler warning
> parsing is performed over make's output. And that is prone to issues because
> of interleaved output and relevant output being sometimes hundreds of lines
> above where make eventually terminates. Something to consider.

I doubt that what I proposed here helps with that in any way...  I'm planning to use the unmodified cl.py script.

Comment 5

[(no longer active)]

Needinfoing glandium for comment 2.

Comment 6

[(not currently active) Ted Mielczarek]

I think we should just fix cl.py to work on non-Windows. The only thing that's Win32-specific in there is file case normalization, which shouldn't be an issue building on Linux. You can just skip that bit for non-Windows.

Comment 7

[Mike Hommey [:glandium]]

I concur with Ted.