695812 - client.mk with RUN_CLIENT_PY doesn't work with mozconfigs that include from mozilla/

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Philippe M. Chiasson (:gozer)]

Attachment: client.mk re-invokes itself after running client.py

i.e. our mac universal builds mozconfig sources:

. mozilla/build/macosx/universal/mozconfig

Which happens very early in client.mk, before we had the time to invoke client.py to clone anything. So, builds break as a result.

The solution I found is similar to how MOZ_BUILD_PROJECTS is implemented. When detecting it must run client.py, client.mk does that and then just re-invokes client.mk, now able to pull in the stuff from mozilla/

Comment 1

[Mark Banner (:standard8)]

Comment on attachment 568159 [details] [diff] [review]
client.mk re-invokes itself after running client.py

If I run without ALWAYS_RUN_CLIENT_PY & co set, then with this patch applied I get:

set -e; \
	for mkfile in build/macosx/universal/flight.mk; do \
	  make -f /Users/moztest/comm/main/src/$mkfile postflight_all TOPSRCDIR=/Users/moztest/comm/main/src MOZ_OBJDIR=/Users/moztest/comm/main/src/../tbuniv MOZ_BUILD_PROJECTS="i386 x86_64"; \
	done
/Users/moztest/comm/main/src/build/macosx/universal/flight.mk:50: /Users/moztest/comm/main/src/../tbuniv/i386/config/autoconf.mk: No such file or directory
make[1]: *** No rule to make target `/Users/moztest/comm/main/src/../tbuniv/i386/config/autoconf.mk'.  Stop.
make: *** [build] Error 2

Comment 2

[Philippe M. Chiasson (:gozer)]

Attachment: client.mk re-invokes itself after running client.py v2

Can you try this one instead, I didn't consider the case without ALWAYS_RUN_CLIENT_PY

Comment 3

[Justin Wood (:Callek)]

Comment on attachment 568499 [details] [diff] [review]
client.mk re-invokes itself after running client.py v2

Overall I can't think of a better solution to this.

My gut feeling though, is that we don't need RAN_CLIENT_PY here since we do ifeq(0,$MAKELEVEL) I have not tested it though.

Idealy *our* mozconfigs won't require anything in m-c though, but I won't ask you to refactor those for this.

Comment 4

[Mark Banner (:standard8)]

(In reply to Justin Wood (:Callek) from comment #3)
> Idealy *our* mozconfigs won't require anything in m-c though, but I won't
> ask you to refactor those for this.

That would require duplicating the mac universal mozconfigs:

http://mxr.mozilla.org/comm-central/source/mozilla/build/macosx/universal/

Which I don't think is really worth doing.

Comment 5

[Philippe M. Chiasson (:gozer)]

(In reply to Justin Wood (:Callek) from comment #3)
> Comment on attachment 568499 [details] [diff] [review] [diff] [details] [review]
> client.mk re-invokes itself after running client.py v2
> 
> Overall I can't think of a better solution to this.

It's somewhat ugly, but I couldn't think of another way either.

> My gut feeling though, is that we don't need RAN_CLIENT_PY here since we do
> ifeq(0,$MAKELEVEL) I have not tested it though.

I thought it was unavoidable, but now that you mention it, I think it can be done.

> Idealy *our* mozconfigs won't require anything in m-c though, but I won't
> ask you to refactor those for this.

Yeah, that was a big surprise for me, I didn't think about that at all.

P.S. I've got a v3 patch in the works that gets away with RUN_CLIENT_PY

Comment 6

[Philippe M. Chiasson (:gozer)]

Attachment: client.mk re-invokes itself after running client.py v3

And as pointed out, there was a simpler solution

Comment 7

[Justin Wood (:Callek)]

Comment on attachment 568725 [details] [diff] [review]
client.mk re-invokes itself after running client.py v3

>diff --git a/client.mk b/client.mk
> endif # MOZ_CURRENT_PROJECT
>+endif # RAN_CLIENT_PY

Nit: comment change to ALWAYS_RUN_CLIENT_PY or else drop it (comment) entirely

Comment 8

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/c005213082eb