54828 - Build should default to non-debug/optimized build.

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, enhancement)

Description

[David Krause]

Now, that we are getting closer to Mozilla 1.0, more ordinary/everyday users are
starting to compile mozilla (mostly on linux and bsd).  They expect that like
most applications they will get a useable optimized build with no debugging.
I've talked to several people that compiled and used mozilla for the first time
and were wondering why it took 1.5 gigs of space and was so slow.  They didn't
realize that they really had a debug build.

So i propose that we make the following options the default unless explicitly
stated to override them in the .mozconfig or in configure:

ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize

Comment 1

[tenthumbs]

On Linux, I would leave --enable-debug. That's pretty much the autoconf way.

Comment 2

[Ben Bucksch (:BenB)]

Please consider that our DEBUG code is *painfully* slow. DEBU is said to usually
costs 5-10% of performance, but a DEBUG Mozilla seems to be twice as slow as an
optimized build. Add to that the fact that gdb is not very good at debugging
Mozilla, and I vote for making the proposed options (plus --strip-libs) the
default. That's what I also use (and I *do* dev, unlike the majority of people
compiling Mozilla).

Comment 3

[tenthumbs]

Most of the slowness is in nspr. If you build outside the source tree you can
say --enable-nspr-autoconf --enable-optimize and get an optimized nspr with
debugging symbols which is*much* faster. You can't do that if you build in the
source tree; maybe you should. Mozilla uses a special nspr branch and most
people who build aren't interested in building some other nspr.

I really really think debugging symbols should be available, otherwise you'll
get lots of fairly useless bug reports.

Comment 4

[Ben Bucksch (:BenB)]

I agree that stack traces are useful, but
- Mozilla official testing builds (nightlies) also come without debugging
symbols
- there's no relativity if it makes Mozilla much slower. If you can fix this by
disabling debugging in NSPR, fine, but I doubt it, given what some of our macros
do in DEBUG mode.

Comment 5

[cls]

Despite the nearness of a NS6 beta3 release and the planned schedule for a
moz1.0 release (still 6 months away), I don't see the project as being ready for
the end user yet.  (It's barely reached dogfood for me but maybe I'm just
picky.)  Sure, being optimized will make things faster...when it's not causing
inexplicable crashes (Bug 53486).  At this point, I think we still need the
debug symbols in order to get a good set of bug reports with stack traces and
lines numbers,etc.  Bumping out to mozilla 1.0.

Comment 6

[hacker formerly known as [e-mail]]

Attachment: Change defaults to debugging off & optimize on

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

r=dmose for the LDAP changes.

Comment 8

[Jaime Rodriguez, Jr.]

Is this the right time to do this? Branch developers are in danger of losing a
day of work if they do not know about this, and they were expecting to get a
debug build.

Comment 9

[cls]

At this point in the game, I don't imagine that defaulting to debug builds is
going to be much help in fixing the issues that are key for release.  We need
people testing optimized builds by default. (And it should lessen the cries of
"You need 1.5 *gig* to build the tree?!?!?") The people that need to make debug
builds know how to do it.  The pending change will be announced to all of the
usual channels (-internal,n.p.m.builds, etc) before the patch is checked in. 

Comment 10

[Jaime Rodriguez, Jr.]

Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.

Comment 11

[Jaime Rodriguez, Jr.]

no real user impact = adt1.0.1-. let's get it into the next release.

Comment 12

[Juan José Mata]

Changing target milestone to 'Future' since 'mozilla1.0.1' came and went already.

Comment 13

[cls]

Mass reassign to default build config owner

Comment 14

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 15

[cls]

Attachment: Build moz optimized & non-debug by default

Comment 16

[cls]

Attachment: Allow nspr to accept multiple --{enable,disable}-{optimize,debug} statements

Comment 17

[cls]

Attachment: Allow ldap to accept multiple --{enable,disable}-{optimize,debug} statements

Comment 18

[Wan-Teh Chang]

Comment on attachment 146532 [details] [diff] [review]
Allow nspr to accept multiple --{enable,disable}-{optimize,debug} statements

r=wtc.

Comment 19

[Benjamin Smedberg]

Comment on attachment 146531 [details] [diff] [review]
Build moz optimized & non-debug by default

woohoo! Of course, advance warning on npm.seamonkey and .builds is in order
before this actually lands.

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 146533 [details] [diff] [review]
Allow ldap to accept multiple --{enable,disable}-{optimize,debug} statements

rs=dmose

Comment 21

[Daniel (Leaf) Nunes]

Comment on attachment 146531 [details] [diff] [review]
Build moz optimized & non-debug by default

woot. so --disable-debug is  a noop now. has this been announced as upcoming in
the newsgroups? (obviously, i haven't been keeping up)

Comment 22

[cls]

I just sent the announcement out to the ngs.  I'm shooting for Friday for
checking in the mozilla changes.  The NSPR & LDAP changes have been checked into
their respective trunks & client branches.

Comment 23

[cls]

The moz patch has been checked in.

Comment 24

[Mike Pinkerton (not reading bugmail)]

i assume this affects camino as well? guess i better go update the build
instructions.

Comment 25

[Steffen Wilberg]

So we default to non-debug, optimized builds on the trunk, but still debug and
non-optimized on the aviary and 1.7-branch. Does that make sense?

trunk:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1335.2.6.2.14&mark=4216-4221,4247-4249,4267-4270#4216
aviary:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1375&mark=4450-4453,4478-4481,4499-4501#4450

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #25)
> So we default to non-debug, optimized builds on the trunk, but still debug and
> non-optimized on the aviary and 1.7-branch. Does that make sense?

yes

Comment 27

[Dan Mosedale (:dmosedale, :dmose)]

biesi: that was a singularly non-helpful response.  I think Steffen has a good
point, because all the builds that we ship should do what good autoconfiscated
packages generally do by default: "./configure && make && make install" should
generate a package suitable for an end-user.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

well, I weren't sure what Steffen was asking...

AIUI, we can't make ./configure && make && make install be suitable for an
end-user, because we can't enable crypto by default due to us export laws, and
end-users certainly want HTTPS.

I agree that making optimized builds by default is a good thing. I don't think
it should change at this point on 1.7 branch (stable branch... changing default
configuration doesn't seem like too good an idea to me).

I guess for FF 1.0 it might be good to enable optimized by default; but it
doesn't matter much because ff has comparatively complicated steps to compile it
anyway (set MOZ_PHOENIX, source browser/config/mozconfig, etc)

Comment 29

[Benjamin Smedberg]

Not for the branch(es), arbitrary change is bad at this point.