Completely wrap subconfigures

RESOLVED FIXED in mozilla34

Status

()

Core
Build Config
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

unspecified
mozilla34
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

4 years ago
In bug 903369, I originally wanted to do that, but the msys mangling made that hard to do. However, to implement bug 1043268, and possible future improvements, it's actually better to do the effort to overcome the mangling.
(Assignee)

Comment 1

4 years ago
Created attachment 8465197 [details] [diff] [review]
Completely wrap subconfigures

While bug 903369 added some kind of wrapping, msys mangling on Windows made
it hard to make the python wrapper invoke subconfigures itself. This change
overcomes this, allowing to run subconfigures entirely independently of
the main configure if necessary, or to do more fancy checks without having
to resort to m4 and shell.
Attachment #8465197 - Flags: review?(mshal)
(Assignee)

Updated

4 years ago
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 2

4 years ago
Created attachment 8465205 [details] [diff] [review]
Completely wrap subconfigures

There was a missing "return".
Attachment #8465205 - Flags: review?(mshal)
(Assignee)

Updated

4 years ago
Attachment #8465197 - Attachment is obsolete: true
Attachment #8465197 - Flags: review?(mshal)
(Assignee)

Comment 3

4 years ago
Created attachment 8465226 [details] [diff] [review]
Completely wrap subconfigures

Duh, forgot to remove a debugging thing.
Attachment #8465226 - Flags: review?(mshal)
(Assignee)

Updated

4 years ago
Attachment #8465205 - Attachment is obsolete: true
Attachment #8465205 - Flags: review?(mshal)
Comment on attachment 8465226 [details] [diff] [review]
Completely wrap subconfigures

>+    dnl Yes, this is horrible. But since msys doesn't preserve environment
>+    dnl variables and command line arguments as they are when transitioning
>+    dnl from msys (this script) to python (below), we have to resort to hacks,
>+    dnl storing the environment and command line arguments from a msys process
>+    dnl (perl), and reading it from python.

What guarantee do we have that perl is always msys? Is it just because that's how we have it in MozillaBuild?

>+    print 'configuring in %s' % os.path.relpath(objdir, os.getcwd())
>+    print 'running %s' % ' '.join(command)
>+    sys.stdout.flush()

Did you mean to leave these print statements as well? Not sure if they were just for debugging, or if they're actually useful.

I won't pretend to understand all of the changes, because this is some serious autoconf+perl+python voodoo, but it seems to work as far as I can tell.
Attachment #8465226 - Flags: review?(mshal) → review+
(Assignee)

Comment 5

4 years ago
(In reply to Michael Shal [:mshal] from comment #4)
> Comment on attachment 8465226 [details] [diff] [review]
> Completely wrap subconfigures
> 
> >+    dnl Yes, this is horrible. But since msys doesn't preserve environment
> >+    dnl variables and command line arguments as they are when transitioning
> >+    dnl from msys (this script) to python (below), we have to resort to hacks,
> >+    dnl storing the environment and command line arguments from a msys process
> >+    dnl (perl), and reading it from python.
> 
> What guarantee do we have that perl is always msys? Is it just because
> that's how we have it in MozillaBuild?

Yes. And we pretty much don't support building with anything else on windows.
https://hg.mozilla.org/mozilla-central/rev/112cf093670b
https://hg.mozilla.org/mozilla-central/rev/759010d95f79
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
QA Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.