539355 - Windows 'B' builds should have '--disable-tests'

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

(Noticed this on bug 534647 bustage.)

Linux:
{
ac_add_options --enable-application=suite
ac_add_options --enable-optimize
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-update-packaging
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-codesighs
}

MacOSX:
{
ac_add_options --enable-application=suite
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-update-packaging
ac_add_options --disable-tests
ac_add_options --enable-codesighs
}

Windows:
{
ac_add_options --enable-application=suite
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-update-packaging
ac_add_options --enable-jemalloc
}

1) Windows uselessly builds tests, isn't it?
3) Linux doesn't need '--enable-optimize' and '--disable-debug' which are the default, aren't they?
2) Ftr, '--enable-codesighs' seems to be available on Windows too...

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Add '--disable-tests' to Windows builds, Sort/Sync' stat/test options

Comment 2

[Robert Kaiser]

Comment on attachment 421376 [details] [diff] [review]
(Av1) Add '--disable-tests' to Windows builds, Sort/Sync' stat/test options

What benefit should this overly complex change give us? Changing those definitions "just because" is not the way to go.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)

*'--disable-tests': faster and "more right" Windows builds.
*synchronization: make it easier to compare which options each builds has (not).

Comment 4

[Robert Kaiser]

(In reply to comment #3)
> *'--disable-tests': faster and "more right" Windows builds.

How much faster? What is "more right"? We should not end up with any notable difference. Also, we probably will end up running "make check" on every build, so we might just need to go the actually completely opposite way.

> *synchronization: make it easier to compare which options each builds has
> (not).

My target is to be as near as possible to Firefox configs, I care less about our different platforms being in sync.

Also, I see no real reason for the various re-orderings that clutter up your patch and make it completely unreadable to me (I can't spot where the actual changes are).

And then, the --enable-codesighs thing completely depends on us being able to run the tests around that and get useful results, which we, AFAIK, can't.

Comment 5

[Robert Kaiser]

Comment on attachment 421376 [details] [diff] [review]
(Av1) Add '--disable-tests' to Windows builds, Sort/Sync' stat/test options

r- in this state. I don't see clear reasons for any of the changes, and - even worse - can't easily spot what the actual changes are due to useless reordering.

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: (Av2) Add '--disable-tests' to Windows builds, on c-1.9.1 [Checkin: See comment 11]

Av1, with comment 5 suggestion(s).

(In reply to comment #4)
> (In reply to comment #3)
> > *'--disable-tests': faster and "more right" Windows builds.
> 
> How much faster? What is "more right"? We should not end up with any notable

No figures, but some for sure. Which is always good to get, and even more when being "overloaded".
At least no more 'B' build breaks caused by a test only changeset. Furthermore, what's the point of having Linux/MacOSX and Windows build differently?
We currently have at least one!

NB: This may clean up some of the packaging report too, though I haven't actually checked that...

> difference. Also, we probably will end up running "make check" on every build,
> so we might just need to go the actually completely opposite way.

I know that Firefox is doing things more and more differently nowadays...
Yet, until we can do as they do, what's the point of keeping a "wrong" config?
If you want to enable tests on L&M (or everywhere), that would be fine with me (though not my preferred option atm), but at least let's have all our platform be as alike as possible.

Comment 7

[Robert Kaiser]

(In reply to comment #6)
> If you want to enable tests on L&M (or everywhere)

I have have not a clue about those dumb tbpl letters and I don't want to have one, but I want to sync up our machines and configs with Firefox again ASAP.

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)
> (In reply to comment #6)
> > If you want to enable tests on L&M (or everywhere)
> 
> I have have not a clue about those dumb tbpl letters and I don't want to have

I meant Linux and MacOSX...

> one, but I want to sync up our machines and configs with Firefox again ASAP.

Good. But is this likely to happen sooner rather than later?

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > If you want to enable tests on L&M (or everywhere)
> > 
> > I have have not a clue about those dumb tbpl letters and I don't want to have
> 
> I meant Linux and MacOSX...

Ah...

> > one, but I want to sync up our machines and configs with Firefox again ASAP.
> 
> Good. But is this likely to happen sooner rather than later?

As I said, ASAP.

Comment 10

[Robert Kaiser]

Comment on attachment 421450 [details] [diff] [review]
(Av2) Add '--disable-tests' to Windows builds, on c-1.9.1
[Checkin: See comment 11]

r+ for the 1.9.1 part only, please leave trunk unchanged, we probably will want to run opt tests there in the future.

Comment 11

[Serge Gautherie (:sgautherie)]

Comment on attachment 421450 [details] [diff] [review]
(Av2) Add '--disable-tests' to Windows builds, on c-1.9.1
[Checkin: See comment 11]


http://hg.mozilla.org/build/buildbot-configs/rev/b3295d01434a
Av2, with comment 10 suggestion(s).

Comment 12

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1) Add '--enable-jemalloc' to Windows 'U' builds, on c-1.9.1 [Checkin: Comment 13]

See bug 539363 comment 0 and 3.

Tests:
*would run more like what we actually release.
*may run faster, iirc.

Comment 13

[Serge Gautherie (:sgautherie)]

Comment on attachment 423804 [details] [diff] [review]
(Bv1) Add '--enable-jemalloc' to Windows 'U' builds, on c-1.9.1
[Checkin: Comment 13]


http://hg.mozilla.org/build/buildbot-configs/rev/96ee03a4336b

Comment 14

[Serge Gautherie (:sgautherie)]

Attachment: (Cv1) Remove '--enable-update-channel=nightly' and '--enable-update-packaging' from all "dep" builds.

FF and TB don't have these.
Remove them, unless we actually want them.

Comment 15

[Robert Kaiser]

Comment on attachment 423814 [details] [diff] [review]
(Cv1) Remove '--enable-update-channel=nightly' and '--enable-update-packaging' from all "dep" builds.

I don't want dep and nightly to be too far away from each other. Also, this is not what the bug has been filed for. Don't waste too much time with the mozconfigs, they're the least of our concerns.

Comment 16

[Serge Gautherie (:sgautherie)]

http://hg.mozilla.org/build/buildbot-configs/rev/57d0c42864c0
Robert Kaiser — update trunk mozconfigs to be in sync with those of Firefox (including activation of bug 536299) - with the exception of Mac not enabling tests anywhere yet (waiting for bug 521523)

http://hg.mozilla.org/build/buildbot-configs/rev/393027e1c61a
Robert Kaiser — enable mochitest-other on trunk

http://hg.mozilla.org/build/buildbot-configs/rev/15318be16a5b
Robert Kaiser — oops, can't symlink linux64 to linux any more now that linux trunk uses a different compiler

http://hg.mozilla.org/build/buildbot-configs/rev/3c518cc26451
Robert Kaiser — hrm, we can't support tests in nightly and release builds atm, as those are static, and building trests fails in that configuration :(

Comment 17

[Robert Kaiser]

Yes, I should have vastly overhauled trunk mozconfigs to match Firefox as closely as we can (and I want dep and nightly to be close to each other as they will merge to one again when we switch to libxul), and I don't want to change branch ones too much, so I don't think there's much else to do in this bug.

Comment 18

[Robert Kaiser]

There has been no objection to my last comment that there's nothing more to do here, so I'll mark this one fixed.

Comment 19

[Serge Gautherie (:sgautherie)]

Attachment: (Hv1) Final update for --*able-tests wrt c-1.9.2/c-c

/macosx/comm-central-trunk/dep/ : bug 521523 is fixed now.
/win32/comm-1.9.2/dep/ : just be explicit.
/win32/comm-1.9.2/release/ : has bug 545172 too.
/win32/comm-central-trunk/dep/ : just be explicit.

Comment 20

[Robert Kaiser]

Comment on attachment 426036 [details] [diff] [review]
(Hv1) Final update for --*able-tests wrt c-1.9.2/c-c

Please just ignore trunk and 1.9.2 for now. trunk will be changed as needed, and we probably will remove explicit --enable-tests completely in the end, the fewer options in mozconfig, the better - 1.9.2 will probably be completely removed from our builds at some time.

Comment 21

[Serge Gautherie (:sgautherie)]

(In reply to comment #18)

No confirmation either: you posted that comment at the very time I was working on comment 19 :-|

(In reply to comment #20)

Yet, why not be consistent in the meantime?

Comment 22

[Robert Kaiser]

(In reply to comment #21)
> (In reply to comment #18)
> 
> No confirmation either: you posted that comment at the very time I was working
> on comment 19 :-|

No comment is usually taken as silent agreement, I couldn't know that you are working on something else.

> (In reply to comment #20)
> 
> Yet, why not be consistent in the meantime?

Ever heard of "never change a running system"?

Comment 23

[Serge Gautherie (:sgautherie)]

(In reply to comment #22)

> No comment is usually taken as silent agreement,

Sure. (You just didn't wait long enough.)

> I couldn't know that you are working on something else.

True, though I did file the bug, assign it to me, etc!

> > (In reply to comment #20)
> Ever heard of "never change a running system"?

How can it be running (right) when missing some "static build with tests is not supported" for example?
I do feel that you silently hijacked this bug and refuse to consider why I opened it for in the first place: too bad :-/

Comment 24

[Robert Kaiser]

> > > (In reply to comment #20)
> > Ever heard of "never change a running system"?
> 
> How can it be running (right) when missing some "static build with tests is not
> supported" for example?

We currently have no need to run tests on static builds, and chances even are that we might never need to (if mailnews external symbols stuff is ready in time, we can switch to libxul).
I currently have more things running on our build machines to run debug builds on all platforms, and we'll only run tests on those for the moment, but even opt builds are not usually static for us, so even if we'd run opt tests the static stuff wouldn't be a problem at all. Only nightlies and releases are static right now, and tests are not run on any of them (we could, if we had tons of build machines, but it will be some time until we do).

> I do feel that you silently hijacked this bug and refuse to consider why I
> opened it for in the first place: too bad :-/

No, I just see that what the summary says has been done for all machines I'll willing to take changes on.