77205 - IDE_Options.h should specify a #pragma for inlining

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Simon Fraser [no longer active]]

Currently IDE_Options.h does not specify inlining settings, leaving it to the 
mercy of each project. And some projects (e.g. DocShell) turn inlining off.

We need to control inlining via IDE_Options.h, and probably use different 
inlining for debug and opt builds. Available #pragmas are:


#pragma auto_inline on | off | reset
#pragma dont_inline on | off | reset
#pragma inline_depth(n)  (1 <= n <= 8)
#pragma inline_depth(smart)

"The smart specifier is the default mode, with 4 passes where the
passes 2-4 are limited to small inline functions. All inlineable functions
are expanded if inline_depth is set to 1-1024."

Comment 1

[Scott Collins]

as agreed, will set inlining to smart for optimized builds, off for debug builds
(until such time as convincing complaints dissuade us); will also explicitly set
the long long option so as not to do two checkins of "IDE_Options.h".

Comment 2

[Steve Dagley]

scc, when are you planning on checking this in?  We need to coordinate with my 
checkin for 3616 as that involves an NSPR header and a full rebuild of the world 
as well.

Comment 3

[Scott Collins]

Well, let me attach a patch first, but I plan to check this in as soon as
feasible after the tree opens for 0.9.1

Comment 4

[Scott Collins]

Attachment: added longlong and inlining pragmas, fixed whitespace

Comment 5

[Scott Collins]

Attachment: same patch as above, but ignoring whitespace so you can see the meat of the change

Comment 6

[Steve Dagley]

I suggets we coordinate checkins for some time either late at night or just 
before the 8am tree closing as we don't want to cause two complete rebuilds for 
the Dep machines

Comment 7

[Scott Collins]

the patch I would check in is 04/25/01 14:33, the second patch is the
--ignore-space-change version of the same patch so you can see the interesting
bits more clearly

Comment 8

[Simon Fraser [no longer active]]

Looks good, sr=sfraser.

Comment 9

[Patrick C. Beard]

r=beard

Comment 10

[chris hofmann]

if it hasn't landed, let's land this in 0.9.2. let drivers know if this creates
problems. thanks.

Comment 11

[Blake Ross]

Missed 0.9.3.

Comment 12

[chris hofmann]

looks like we could live without these for 0.9.4.   let me know if this is a
mistake.  moving out...

Comment 13

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 14

[Jonadab the Unsightly One (Nathan Eady)]

Too late for 0.9.6, this needs retargeting.

Comment 15

[chris hofmann]

unsetting the target milestone until we can get a good one.

Comment 16

[Simon Fraser [no longer active]]

Let's try and get these in with the Pro 7 transition.

Comment 17

[Conrad Carlen (not reading bugmail)]

How well tested is a build done this way? Are we absolutely sure it's safe? I
think we need to use both of these pragmas, but rolling in changes which change
code generation, in addition to the other changes happening, could make
potential problems harder to isolate.
In other words, if you're having heart surgery, wouldn't you want to recover
from that operation before getting a pacemaker? 

Comment 18

[Serge Gautherie (:sgautherie)]

<http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/build/mac/IDE_Options.h>
{{
3.14	seawood%netscape.com	2003-06-10 13:18	 	Removing old cfm build files. Use the CFM_LAST_RITES tag to resurrect. r=macdev
}}