682898 - Create a test to ensure comm-central and mozilla-central configuration harness is in sync

Status: RESOLVED FIXED

(Thunderbird :: Build Config, defect)

Description

[Philippe M. Chiasson (:gozer)]

Bug 656049 copied some of mozilla-central's configuration harness into comm-central, and they will diverge over time.

Create a make check test that verifies that the files are identical and warns otherwise, so we can more easily keep them in sync.

Comment 1

[Justin Wood (:Callek)]

Attachment: Test It

Ok, this patch does a few things:

#1 I decided to reuse the m-c test python program. We are not running it prior to a normal build, so we can rely on it being present.
#2 I did *not* set it to run in client.mk as m-c currently (since that was done to fail-early for them) since we can *only* expect orange and not blocking people, since m-c can change from under us.
#3 the exceptions file only applies to "current" dir, and only files that are in _copy_ (c-c) and known to be absent or different from files in _source_ (m-c) need to be listed.
#4 flight.mk needs to be different, since we push mozilla/ to many paths there, and we add mozmill stuff to it.

Running this locally passes.

Comment 2

[Justin Wood (:Callek)]

Comment on attachment 556757 [details] [diff] [review]
Test It

alt review from KaiRo, as I'd rather not let a test for checked-in-code languish, and Mark is taking a while.

Comment 3

[Mark Banner (:standard8)]

Would we want to do something like bug 677577 instead, so that we can catch this at an earlier stage of the build cycle, or do we just want our tests/code to run anyway, and just flag the fact these files are different?

Comment 4

[Justin Wood (:Callek)]

(In reply to Mark Banner (:standard8) from comment #3)
> Would we want to do something like bug 677577 instead, so that we can catch
> this at an earlier stage of the build cycle, or do we just want our
> tests/code to run anyway, and just flag the fact these files are different?

IMO, no. I didn't want us to fail early for this code. The chances of the m-c copies changing in an incompat way are slim. I felt it wasn't worth failing early on this, once this trips we can just land the fix.

The m-c side fails early because everything it is testing is in the same repo. So if it fails it was due to the checkin where it failed on, in our case, it would be do to a m-c checkin.

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 556757 [details] [diff] [review]
Test It

>+check::
>+	@$(PYTHON) $(TOPSRCDIR)/mozilla/js/src/config/check-sync-dirs.py \
>+	   $(TOPSRCDIR)/build $(TOPSRCDIR)/mozilla/build
>+

You should be using $(topsrcdir) as per the rest of the file - otherwise this will fail on Mac and probably Linux as well.

r=me with that fixed.

Comment 6

[Justin Wood (:Callek)]

http://hg.mozilla.org/comm-central/rev/d95685da754f with nit addressed