The default bug view has changed. See this FAQ.

Reject building with pymake

RESOLVED FIXED in mozilla33

Status

()

Core
Build Config
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

unspecified
mozilla33
All
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

3 years ago
Now that comm-central builds fine without pymake, it's time to say goodbye. And in fact, since bug 1022348 landed, pymake builds are broken anyways (and the good thing is that few people complained they were failing to build).
(Assignee)

Comment 1

3 years ago
Also, not having to care for pymake helps make the build system changes I'm planning for soon.

Comment 2

3 years ago
I'll grant r+ without seeing the patch.
We need to ensure l10n and related infra (including release jobs) will work fine without pymake, even when calling the old pymake invoker directly (e.g. python ...make.py) for certain buildbot parts.

I "seem to recall" that we passed directly to mozmake when invoked that way, if in path, but wanted to call it out
(Assignee)

Comment 4

3 years ago
We can surely do this in several steps:
- Remove pymake support from mach (doesn't impact automation)
- Make the change from bug 927672 not fallback to using pymake if mozmake is not present (and here we can see if that breaks l10n)
- Actively reject pymake in config/baseconfig.mk.

For step 2, that essentially depends on whether those builds are using tooltool or not.
(Assignee)

Comment 5

3 years ago
(In reply to Mike Hommey [:glandium] from comment #4)
> For step 2, that essentially depends on whether those builds are using
> tooltool or not.

According to the logs, l10n builds don't use tooltool. (not only on windows, btw)
(Assignee)

Updated

3 years ago
Depends on: 1027929
(Assignee)

Comment 6

3 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1027929#c1

Oh, the irony. It would break nightly l10n, but not release l10n.
(Assignee)

Comment 7

3 years ago
Actually, release l10n builds would break for a different reason: they don't run tooltool in the topsrcdir.
(Assignee)

Comment 8

3 years ago
Created attachment 8443377 [details] [diff] [review]
Reject builds with pymake

Please do look at this patch ;)
Attachment #8443377 - Flags: review?(gps)
(Assignee)

Comment 9

3 years ago
Created attachment 8443379 [details] [diff] [review]
Remove all sorts of build system code dedicated to pymake

Note the weird thing removed from config/rules.mk ; the test didn't work there because L10NBASEDIR is always set (see config/config.mk)
Attachment #8443379 - Flags: review?(gps)
(Assignee)

Updated

3 years ago
Depends on: 1028100
Comment on attachment 8443377 [details] [diff] [review]
Reject builds with pymake

Review of attachment 8443377 [details] [diff] [review]:
-----------------------------------------------------------------

I think I have a new favorite patch of the year.

::: config/baseconfig.mk
@@ +29,3 @@
>  # strictly above 4.0.
> +ifdef .PYMAKE
> +$(error Pymake is not supported)

Let's make this a little more user friendly since I know some people bypass client.mk and will see this. How about:

Pymake is no longer supported. Please upgrade to MozillaBuild 1.9 or newer and build with 'make'.
Attachment #8443377 - Flags: review?(gps) → review+

Updated

3 years ago
Attachment #8443379 - Flags: review?(gps) → review+

Updated

3 years ago
Blocks: 1028678
(Assignee)

Comment 11

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/49cadfcde709
https://hg.mozilla.org/integration/mozilla-inbound/rev/bcd694f0e95d
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/59b0072d64aa next to bug 1027497 for B2G Windows build bustage: https://tbpl.mozilla.org/php/getParsedLog.php?id=42399092&tree=Mozilla-Inbound
Flags: needinfo?(mh+mozilla)
(Assignee)

Comment 13

3 years ago
Created attachment 8445628 [details] [diff] [review]
Reject builds with pymake

What failed at landing is that the b2g simulator thing is back-calling make through the mach code in build_xpi.py. The best idea I have is to export MAKE, and make mach try that value too.
Attachment #8445628 - Flags: review?(gps)
(Assignee)

Updated

3 years ago
Attachment #8443377 - Attachment is obsolete: true
(Assignee)

Comment 14

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=40b0a677b283
Flags: needinfo?(mh+mozilla)
Comment on attachment 8445628 [details] [diff] [review]
Reject builds with pymake

Review of attachment 8445628 [details] [diff] [review]:
-----------------------------------------------------------------

my reluctant r+ on that b2g simulator patch comes back to bite us.

I'll re-land this for you since I assume you are sleeping.
Attachment #8445628 - Flags: review?(gps) → review+
https://hg.mozilla.org/integration/fx-team/rev/8aac3c8dc7bb

(inbound was closed)
Status: NEW → ASSIGNED
(Assignee)

Comment 17

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/df7a27d2bb7e
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/8aac3c8dc7bb
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla33
https://hg.mozilla.org/mozilla-central/rev/df7a27d2bb7e
https://hg.mozilla.org/mozilla-central/rev/2ddf136b173d
Depends on: 1031009
You need to log in before you can comment on or make changes to this bug.