40013 - Spurious ToolServer Macintosh build dependancy

Status: RESOLVED DUPLICATE of bug 98349

(SeaMonkey :: Build Config, defect, P3)

Description

[Gordon Henriksen]

[Low-hanging fruit for someone who was annoyed by the build process.]

ToolServer is currently only being used to build NSPR stub libraries, although 
CodeWarrior 5, at least, is fully capable of making those on its own. It appears that 
the only stub library being built is NSStdLib. I was able to modify the 
:lib:mac:NSStdLib:NSStdLib.mcp[Stubs] target to use CW's built-in facilities. There's 
another RunTSScript target, :lib:mac:NSRuntime:NSRuntime.mcp[Stubs], but it doesn't 
appear to get built. I also updated that for CW, though, so that the project can load 
without error. Doing these two tasks, I was able to disable (compress) ToolServer, 
MPW, and the RunTSScript "compiler" and then successfully built a working 
MozillaDebug.

Although I didn't change any source files, there are 4 ToolServer scripts which can be 
removed from the repository if these projects are checked in. The existance of these 
files is benign, but they're unnecessary. They are :lib:mac:NSRuntime:NSRuntime.mcp, 
:lib:mac:MacMemoryAllocator:MemAllocator.exp_MakeStubs and 
:MemAllocator.exp_TS, and :lib:mac:NSStdLib:NSStdLib:NSStdLib.exp_TS.

Comment 1

[Gordon Henriksen]

Attachment: NSStdLib.mcp without ToolServer dependencies.

Comment 2

[Gordon Henriksen]

Attachment: NSStdLib.mcp without ToolServer dependency.

Comment 3

[Gordon Henriksen]

Attachment: NSRuntime.mcp without ToolServer dependency.

Comment 4

[Gordon Henriksen]

Sorry, didn't realize the first of those attachments actually went through.

Comment 5

[Wan-Teh Chang]

Gordon (Sheridan), Simon, could you help me
review this bug?  Thanks.

Is it possible to do without the stub library
(NSStdLib) altogether?

Comment 6

[Gordon Henriksen]

Not without some work: NSRuntime has a recursive dependancy with NSStdLib.

Comment 7

[Simon Fraser [no longer active]]

We can indeed remove ToolServer from the mozilla build process.

Comment 8

[Wan-Teh Chang]

Simon, why do we need the stub library at all?

Comment 9

[Simon Fraser [no longer active]]

Because we need to resolve a circular dependency between NSRuntime and NSStdLib.

Comment 10

[Simon Fraser [no longer active]]

Move to browser component.

Comment 11

[Simon Fraser [no longer active]]

Build coinfig issue, can be dealt with later.

Comment 12

[rubydoo123]

adding text to whiteboard

Comment 13

[Simon Fraser [no longer active]]

Mozilla0.9

Comment 14

[rubydoo123]

assigning to sdagley

Comment 15

[Andrew Thompson]

*** Bug 75136 has been marked as a duplicate of this bug. ***

Comment 16

[Andrew Thompson]

Transferring blocks from duplicate bug.

This blocks us from building in CodeWarrior 6 on Mac OS X.

I'll test the attached file tonight and see if it works. If so, I suggest we get
this in ASAP.

Comment 17

[Andrew Thompson]

Looking good. I'll attach updated versions of NSRuntime and NSStdLib based off of 
the April 08 2001 trees. 

I've even done CodeWarrior 5 and 6 versions, though the 5 is all that will need 
to be checked in. Can we *please* do this before all this work bit rots? 

Gordon's other comments about removing dead files still apply.
Thanks for this one...

Comment 18

[Andrew Thompson]

Attachment: CodeWarrior 6 version of NSRuntime.mcp

Comment 19

[Andrew Thompson]

Attachment: CodeWarrior 6 version of NSStdLib.mcp

Comment 20

[Andrew Thompson]

Attachment: CodeWarrior 5 version of NSRuntime.mcp

Comment 21

[Andrew Thompson]

Attachment: CodeWarrior 5 version of NSStdLib.mcp (all files are Stuffed)

Comment 22

[Simon Fraser [no longer active]]

Why do we need a new version of NSRuntime.mcp for Pro 5?

Comment 23

[Andrew Thompson]

I updated the Stubs target in NSRuntime so it would actually build the Stub
library for NSRuntime correctly. If this truly obsolete then its presumably
better to just delete the Stubs target altogether from NSRuntime.mcp.

Comment 24

[Marek Z. Jeziorek]

Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.

Comment 25

[Jussi-Pekka Mantere]

Moving to 0.9.3.

Comment 26

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 27

[Steve Dagley]

This will finally go away once we move to a CW Pro 7 based build

Comment 28

[Andrew Thompson]

*** This bug has been marked as a duplicate of 98349 ***