If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

SeaMonkey
Build Config
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows Server 2003
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Assignee)

Description

8 years ago
(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...
Flags: in-testsuite-
(Assignee)

Comment 1

8 years ago
Created attachment 421376 [details] [diff] [review]
(Av1) Add '--disable-tests' to Windows builds, Sort/Sync' stat/test options
Attachment #421376 - Flags: review?(kairo)
(Assignee)

Updated

8 years ago
Depends on: 539363

Comment 2

8 years ago
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.
(Assignee)

Comment 3

8 years ago
(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

8 years ago
(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

8 years ago
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.
Attachment #421376 - Flags: review?(kairo) → review-
(Assignee)

Comment 6

8 years ago
Created attachment 421450 [details] [diff] [review]
(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.
Attachment #421376 - Attachment is obsolete: true
Attachment #421450 - Flags: review?(kairo)
(Assignee)

Updated

8 years ago
Attachment #421450 - Attachment description: 539355-Av2_disable-tests.diff → (Av2) Add '--disable-tests' to Windows builds

Comment 7

8 years ago
(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.
(Assignee)

Comment 8

8 years ago
(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

8 years ago
(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

8 years ago
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.
Attachment #421450 - Flags: review?(kairo) → review+
(Assignee)

Comment 11

8 years ago
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).
Attachment #421450 - Attachment description: (Av2) Add '--disable-tests' to Windows builds → (Av2) Add '--disable-tests' to Windows builds [Checkin: See comment 11]
(Assignee)

Comment 12

8 years ago
Created attachment 423804 [details] [diff] [review]
(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.
Attachment #423804 - Flags: review?
(Assignee)

Updated

8 years ago
Attachment #423804 - Flags: review? → review?(kairo)

Updated

8 years ago
Attachment #423804 - Flags: review?(kairo) → review+
(Assignee)

Updated

8 years ago
Attachment #421450 - Attachment description: (Av2) Add '--disable-tests' to Windows builds [Checkin: See comment 11] → (Av2) Add '--disable-tests' to Windows builds, on c-1.9.1 [Checkin: See comment 11]
(Assignee)

Comment 13

8 years ago
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
Attachment #423804 - Attachment description: (Bv1) Add '--enable-jemalloc' to Windows 'U' builds, on c-1.9.1 → (Bv1) Add '--enable-jemalloc' to Windows 'U' builds, on c-1.9.1 [Checkin: Comment 13]
(Assignee)

Comment 14

8 years ago
Created attachment 423814 [details] [diff] [review]
(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.
Attachment #423814 - Flags: review?(kairo)

Comment 15

8 years ago
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.
Attachment #423814 - Flags: review?(kairo) → review-
(Assignee)

Comment 16

8 years ago
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 :(
(Assignee)

Updated

8 years ago
Blocks: 492421

Comment 17

8 years ago
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.
(Assignee)

Updated

8 years ago
Blocks: 543396
(Assignee)

Updated

8 years ago
Blocks: 545172
(Assignee)

Updated

8 years ago
Blocks: 536299
Depends on: 521523

Comment 18

8 years ago
There has been no objection to my last comment that there's nothing more to do here, so I'll mark this one fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

8 years ago
Created attachment 426036 [details] [diff] [review]
(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.
Attachment #426036 - Flags: review?(kairo)

Comment 20

8 years ago
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.
Attachment #426036 - Flags: review?(kairo) → review-
(Assignee)

Comment 21

8 years ago
(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

8 years ago
(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"?
(Assignee)

Comment 23

8 years ago
(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

8 years ago
> > > (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.
You need to log in before you can comment on or make changes to this bug.