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

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Benjamin Smedberg]

Attachment: Toplevel makefile pymake forwarding, rev. 1

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.

Comment 1

[(not currently active) Ted Mielczarek]

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?

Comment 2

[Benjamin Smedberg]

Yes, but that involves changing the build automation, which seems like a long-term project at least.

Comment 3

[(not currently active) Ted Mielczarek]

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.)

Comment 4

[Chris AtLee [:catlee]]

Changes to build automation are pretty minor, and can be landed as soon as the changes to client.mk exist on all branches.

Comment 5

[Chris AtLee [:catlee]]

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

Comment 6

[Benjamin Smedberg]

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?

Comment 7

[(not currently active) Ted Mielczarek]

We could also have some short-circuiting ifdef UNIVERSAL_BUILD based on target arch or something.

Comment 8

[Benjamin Smedberg]

Attachment: Forward targets from client.mk to the build system, rev. 1

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"

Comment 9

[Benjamin Smedberg]

Attachment: Forward targets from client.mk to the build system, rev. 1.1

Added check::

Comment 10

[Benjamin Smedberg]

Attachment: Forward targets from client.mk to the build system, rev. 2

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.

Comment 11

[Benjamin Smedberg]

Attachment: Implement forwarding through client.mk, buildbot-configs patch

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

Comment 12

[Benjamin Smedberg]

Attachment: Implement forwaring through client.mk, buildbotcustom patch

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 13

[(not currently active) Ted Mielczarek]

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.

Comment 14

[Axel Hecht [:Pike]]

Do we need the same thing for the l10n make targets?

Comment 15

[Chris Cooper [:coop] (he/him)]

Mass close of pymake-related bugs.