Closed Bug 485411 Opened 12 years ago Closed 3 years ago

Work around the fact that tinderbox calls `make package` without using pymake

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: benjamin, Unassigned)

References

Details

(Whiteboard: [pymake])

Attachments

(3 files, 3 obsolete files)

When my mozconfig specifies using pymake, the tinderbox still calls `make package` directly. This works on linux/mac, but the Windows-style paths means you can't mix gmake and pymake there.

This hack takes the toplevel makefile and forwards all calls to pymake through a make-anything pattern rule and an ifdef.
Attachment #369559 - Flags: review?(ted.mielczarek)
Blocks: 485412
Comment on attachment 369559 [details] [diff] [review]
Toplevel makefile pymake forwarding, rev. 1

This is pretty icky. Didn't we talk about forwarding calls through client.mk instead?
Yes, but that involves changing the build automation, which seems like a long-term project at least.
I don't know, should only be a few lines of patch. (Although you'd have to land the build patch on 1.9.1 as well before landing that.)
Changes to build automation are pretty minor, and can be landed as soon as the changes to client.mk exist on all branches.
Other than 'package', are there other targets that need to be added to client.mk?

A quick scan of our automation code turns up:
package
package-tests
upload (already done)
buildsymbols
uploadsymbols
installer
The tricky part, if it can be called that, is that the buildbot currently calls these targets in only one side of the UB builds. Perhaps if there are multiple MOZ_BUILD_PROJECTS we should forward to the first one?
We could also have some short-circuiting ifdef UNIVERSAL_BUILD based on target arch or something.
Attachment #369559 - Flags: review?(ted.mielczarek)
The MOZMAKE bit is slightly convoluted because:

* MAKE set in the environment overrides make implicit values of $(MAKE)
* AC_PATH_PROGS misinterprets multi-item values of MAKE such as "python -O make.py"
Attachment #370893 - Flags: review?(ted.mielczarek)
Added check::
Attachment #369559 - Attachment is obsolete: true
Attachment #370893 - Attachment is obsolete: true
Attachment #370923 - Flags: review?(ted.mielczarek)
Attachment #370893 - Flags: review?(ted.mielczarek)
Attachment #370923 - Flags: review?(ted.mielczarek)
Going through buildbot stuff I found more entry points, and so I created some variables which make it easy to add entry points and keep everything in sync.
Attachment #370923 - Attachment is obsolete: true
Attachment #370943 - Flags: review?(ted.mielczarek)
This is the changes necessary for buildbot-configs to support client.mk forwarding. I'm not going to bother requesting review until the client.mk bits are landed on trunk and 1.9.1
Patch against buildbotcustom. The major change here is that the various unit-test steps have a different workdir (the source directory, not the objdir).

It's possible, even likely, that some variant of this client.mk patch will need to land in comm-central as well.
Comment on attachment 370943 [details] [diff] [review]
Forward targets from client.mk to the build system, rev. 2

+FORWARD_TO_ALL_PROJECTS = \

Please add xpcshell-tests to this list.

+FORWARD_TO_FIRST_PROJECT = \

As I said on IRC, I'm not sure how this will work for something like Fennec or FF+XR, but I guess we can cross that bridge when we come to it.
Attachment #370943 - Flags: review?(ted.mielczarek) → review+
Do we need the same thing for the l10n make targets?
Assignee: benjamin → nobody
Mass close of pymake-related bugs.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.