make mac CFM static build

VERIFIED WONTFIX

Status

SeaMonkey
Build Config
VERIFIED WONTFIX
17 years ago
4 years ago

People

(Reporter: Cathleen, Assigned: Simon Fraser)

Tracking

({embed, topembed-})

Trunk
mozilla1.1alpha
PowerPC
All
embed, topembed-
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 12 obsolete attachments)

8.37 KB, text/plain
Details
13.51 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
 
(Reporter)

Updated

17 years ago
Blocks: 46775
(Reporter)

Comment 1

17 years ago
Here is a break down list of libs required per install option (mac mozilla)

minimal xpcom lib (required by installer)
----------------------
viewer:Components:libjar.shlb 
viewer:Components:xpinstall.shlb 
viewer:Components:unicharutil.shlb 
viewer:Essential Files:JavaScript.shlb 
viewer:Essential Files:libreg.shlb 
viewer:Essential Files:LiveConnect.shlb 
viewer:Essential Files:NSPR20.shlb 
viewer:Essential Files:NSRuntime.shlb 
viewer:Essential Files:NSStdLib.shlb 
viewer:Essential Files:oji.shlb 
viewer:Essential Files:xpcom.shlb 
viewer:Essential Files:xpistub.shlb 
viewer:Essential Files:zlib.shlb 


browser lib
----------------------
viewer:Essential Files:gfx.shlb 
viewer:Essential Files:libimg.shlb 
viewer:Essential Files:libutil.shlb 
viewer:Essential Files:RaptorShell.shlb 
viewer:Essential Files:widget.shlb 
viewer:Essential Files:NSSckbi.shlb
viewer:Components:docshell.shlb 
viewer:Components:AppShell.shlb 
viewer:Components:Caps.shlb 
viewer:Components:chardet.shlb 
viewer:Components:ChomeRegistry.shlb 
viewer:Components:content.shlb
viewer:Components:Cookie.shlb 
viewer:Components:appcomps.shlb 
viewer:Components:dom.shlb 
viewer:Components:EditorCore.shlb 
viewer:Components:EditorTxmgr.shlb 
viewer:Components:EmbedComponents.shlb
viewer:Components:FindComponent.shlb 
viewer:Components:gifdecoder.shlb 
viewer:Components:htmlparser.shlb 
viewer:Components:jpgdecoder.shlb 
viewer:Components:JSLoader.shlb 
viewer:Components:jsurl.shlb 
viewer:Components:layout.shlb 
viewer:Components:libpref.shlb 
viewer:Components:lwbrk.shlb 
viewer:Components:mngdecoder.shlb
viewer:Components:Mork.shlb 
viewer:Components:mozBrowser.shlb 
viewer:Components:nslocale.shlb 
viewer:Components:PIPNSS.shlb
viewer:Components:PIPPKI.shlb
viewer:Components:plugin.shlb 
viewer:Components:pngdecoder.shlb 
viewer:Components:prefm.shlb 
viewer:Components:profile.shlb 
viewer:Components:RDFLibrary.shlb 
viewer:Components:RegViewer.shlb 
viewer:Components:shistory.shlb 
viewer:Components:strres.shlb 
viewer:Components:TextServices.shlb
viewer:Components:uconv.shlb 
viewer:Components:ucth.shlb 
viewer:Components:ucvcn.shlb 
viewer:Components:ucvibm.shlb 
viewer:Components:ucvja.shlb 
viewer:Components:ucvko.shlb 
viewer:Components:ucvlatin.shlb 
viewer:Components:ucvtw.shlb 
viewer:Components:ucvtw2.shlb 
viewer:Components:uriloader.shlb 
viewer:Components:view.shlb 
viewer:Components:Wallet.shlb 
viewer:Components:WalletViewers.shlb 
viewer:Components:xfer.shlb 
viewer:Components:XPConnect.shlb 
viewer:Components:xmlextras.shlb
viewer:Components:transformiix.shlb
viewer:Components:gfx2.shlb
viewer:Components:libimg2.shlb
viewer:Components:pngdecoder2.shlb
viewer:Components:gifdecoder2.shlb
viewer:Components:jpegdecoder2.shlb
viewer:Components:icondecoder.shlb
viewer:Components:Necko.shlb 
viewer:Components:Necko2.shlb
viewer:Components:Cache.shlb 


mail lib
----------------------
viewer:Components:MsgAddrbook.shlb 
viewer:Components:mimeEmitter.shlb 
viewer:Components:mailnews.shlb 
viewer:Components:Mime.shlb 
viewer:Components:MsgCompose.shlb 
viewer:Components:MsgDB.shlb 
viewer:Components:MsgImap.shlb 
viewer:Components:MsgLocal.shlb 
viewer:Components:MsgNews.shlb 
viewer:Components:vcard.shlb 
viewer:Components:smime.shlb
viewer:Components:signed.shlb
viewer:Components:msgImport.shlb
viewer:Components:msgImportText.shlb
viewer:Components:msgImportEudora.shlb
viewer:Components:AbSyncSvc.shlb 
viewer:Components:mozldap.shlb
viewer:Essential Files:LDAPClient.shlb

Comment 2

17 years ago
Created attachment 35897 [details] [diff] [review]
diff of MozillaCheckoutList.txt, which still fails to build

Comment 3

17 years ago
Created attachment 35899 [details]
MacPerl and CodeWarrior diagnostics, for prev attachment

Comment 4

17 years ago
Created attachment 36147 [details] [diff] [review]
patch to pull STATIC_BUILD_20010523_BUILD

Comment 5

17 years ago
Created attachment 36149 [details]
MacPerl diagnostic for BuildMozillaDebug.pl w/prev attachment
(Assignee)

Comment 6

17 years ago
So the DOM Project doesn't build. Now go back, open the project, try to build it 
manually, and inspect the errors.

Comment 7

17 years ago
Created attachment 36155 [details]
CW diagnostics for dom's nsJSEnvironment.cpp
(Assignee)

Comment 8

17 years ago
Does the static build work for people on other platforms? You should try doing 
the static build on Windows and Mac at the same time, because all you are seeing 
here are genuine build errors.

Comment 9

17 years ago
dprice is working off the same branch for windows, at the same time. kandrot had 
done the original static linking work, on LINUX, on an earlier branch. It'll be 
interesting to see if they have/had run into the same problem, which for the 
record is:
Per previous attachment:

The problem is not that ` NS_IMETHOD GetTimeStamp(DOMTimeStamp *aTimeStamp) = 0;` 
is a pure virtual function, because there are other pure viruals, earlier in this 
class (class nsIDOMEvent).

When using CW's "preprocess" option on nsJSEnvironment.cpp, I get the line:
virtual nsresult GetTimeStamp(DOMTimeStamp *aTimeStamp) = 0;

The key problem, I think, is that there is no previous "DOMTimeStamp" decl in the 
preprocessed file.

(Reporter)

Comment 10

17 years ago
what are the errors? are they in XPCOM?  If that's true, I think waterson has 
some patches for XPCOM that we need.  :-)
(Reporter)

Comment 11

17 years ago
never mind.  waterson had already checked in XPCOM changes. see bug 46775

Comment 12

17 years ago
responding to sfraser's 5/25 12:21 comment:
dprice says, on windows, he had particular problems getting the correct versions 
of "nspr, psm, ldap, accessible, imglib2 and gfx2", and had to massage his 
mozilla/client.mak to get the correct versions.

So, this leads me back to the question: do we really have the correct 
MozillaCheckoutList.txt? When cross-referencing dprice's list of problems with my 
current version of MozillaCheckoutList.txt, NSPRPUB_CLIENT_BRANCH and 
LDAPCSDK_40_BRANCH stand out as questionable.

mozilla/nsprpub,        			NSPRPUB_CLIENT_BRANCH
mozilla/security/nss,   			NSS_CLIENT_TAG
mozilla/security/psm,				STATIC_BUILD_20010523_BRANCH   
mozilla/security/manager,			STATIC_BUILD_20010523_BRANCH
mozilla/accessible,					STATIC_BUILD_20010523_BRANCH
DirectorySDKSourceC,    			LDAPCSDK_40_BRANCH
mozilla/lib/mac/Instrumentation,	STATIC_BUILD_20010523_BRANCH
mozilla/gfx2,						STATIC_BUILD_20010523_BRANCH
mozilla/modules/libpr0n,			STATIC_BUILD_20010523_BRANCH
SeaMonkeyAll,						STATIC_BUILD_20010523_BRANCH

If anybody can certify this file as correct, I'm open to suggestions of how to 
proceed from here, given that the build problem laid out in previous attachments, 
still exists.
(Reporter)

Comment 13

17 years ago
Steve, I think you're tree is messed up.  all of them should have 
STATIC_BUILD_20010523_BRANCH tag.

On windows, I just did a check out by
> cvs co -r STATIC_BUILD_20010523_BRANCH mozilla/client.mak

than I did
> nmake /f client.mak 

that'll pull the right branch for you. this applies to all directories.

You probably need to wipe out your tree and pull a clean one.

Comment 14

17 years ago
If you've checked out the mac checkout list file from the branch and it contains
pointers to branches that are not your static build branch, you need to fix that
file and check it back in on the branch.  You should also confirm that those
files have been correctly branched (although from cathleen's comments it sounds
like win32 is pulling the files correctly).  Both mac and win32 check out files
and directories specific to that platform that are not checked out on Linux
which can cause problems if you're trying to branch the whole tree and only
branch a tree checked out on one platform via the build scripts.

Comment 15

17 years ago
STATUS:
The source I pulled yesterday has built.

The executable fails after about 10 seconds, with a type "12" error while
loading the first page (www.mozilla.org).

PLANS:
I'm not going to worry about the executable failure right now. My first goal is
to get a statically linked build. 
(Assignee)

Comment 16

17 years ago
Current status here is that we can't find a way to script CodeWarrior to create 
new project targets for the static build.

I have managed to get the XML::DOM Perl module working on Mac, and I can parse an 
XML-format project, which should make DOM operations to clone targets pretty 
easy.
(Assignee)

Comment 17

17 years ago
To install XML::DOM for MacPerl:

1. Get and install
     http://www.perl.com/CPAN/authors/id/A/AS/ASANDSTRM/XML-Parser-2.27-bin-1-
MacOS.tgz
2. Get and install XML::DOM
     http://www.cpan.org/authors/id/T/TJ/TJMATHER/XML-DOM-1.31.tar.gz

3. Hack MacPerl:site_perl:XML:DOM:DOM.pm so that it's happy with XML::Parser 
2.27:

-   my $needVersion = '2.28';
+   my $needVersion = '2.27';       # smfr hack. Was 2.28

(note: I've no idea what bad side-effects this might have).

To install MacPerl modules, drag the .tar.gz (or .tgz) file onto "installme.plx" 
in the MacPerl folder.
If you need some Perl to get all the projects into XML, it's checked into the
CW7_20010609_BRANCH. The routine of interest is export_project in
CodeWarriorLib.pm. You'll have to hack the build scripts to call this for each
project. Also, the export will fail on projects which contain bogus access
paths. In the build script hackery, I put in code that printed the success or
failure and then went through and removed bad paths from the ones that failed
(10 or so)

Comment 19

17 years ago
Response to Simon Fraser 2001-06-27 19:45:

Thanks for the XML::DOM for MacPerl install instructions.

I've failed on the last step, as my copy of mozilla tools
has no `DOM.pm`; and I can find none in the current MacPerl folder
on `4G Server Storage` , either.
(On the server, there isn't even an XML folder, under the site_perl folder)
(Assignee)

Comment 20

17 years ago
Random notes:
* You can clone a target in the XML by cloning the subtree under the <TARGET>
  tag. The new target must have a unique <SETTING><TARGETNAME>, and there must
  be a <ORDEREDTARGET> entry under <TARGETORDER> for the new target.

* XML::DOM collapses empty elements into the <VALUE/> form when writing XML,
  and CW Pro 5 cannot handle these (requiring <VALUE></VALUE>. Pro 6 handles
  them fine.

So I think it's going to be do-able to use this to make all the static lib 
targets.
(Assignee)

Comment 21

17 years ago
Created attachment 40600 [details]
ProjectXML.pm perl module for project manipulation
(Assignee)

Comment 22

17 years ago
The attached perl module can be used to read in an XML project, clone a named 
target, change the target settings to be a static lib target, and write the XML 
out again. It works with CW Pro 6, currently. Usage is something like:

my $doc = ProjectXML::ParseXMLDocument("Test.mcp.xml");
ProjectXML::CloneTarget($doc, "Test.shlb", "Test.lib");
ProjectXML::SetAsStaticLibraryTarget($doc, "Test.lib", "TestOutput.lib");
ProjectXML::WriteXMLDocument($doc, "Test_out.xml");
ProjectXML::DisposeXMLDocument($doc);
(Assignee)

Comment 23

17 years ago
More recent patch in bug 88340.
(Assignee)

Comment 24

17 years ago
I currently have things working to the point where we can script the creation of 
static library targets for all shared lib targets in projects in the build. There 
is a little more work to do to "fix up" these created targets (e.g. removing 
linkage with other libraries), but that should be relatively easy.

What we will need is a Mac version of the Perl XML::Parser module vers. 2.28, 
since XML::DOM depends on that.

Comment 25

17 years ago
Branch is still being cut, sorry we had cvs errors.
Branch will be called: STATIC_BUILD_20010628_BRANCH
ETA to finish branch cut, 8pm Friday.

Comment 26

17 years ago
branch is ready now, both mozilla & ns trees.

Comment 27

17 years ago
the branch, STATIC_BUILD_20010628_BRANCH, builds. It runs -- I am adding this
comment from the app that was built(optimized) from it.

The only major source problem which I encountered, had to do with corruption of
the source during the pull, rather than any problem with the official source
itself. For the record:


Error   : undefined identifier 'yption'
nsInternetSearchService.cpp line 5760   yption

`yption` was an extra line falsely added, at EOF, during the pull.
(Assignee)

Comment 28

17 years ago
> `yption` was an extra line falsely added, at EOF, during the pull.

That's a bug in the version of MacCVS Pro that you're using. Grab MacCVS Pro 
2.7d7.
> That's a bug in the version of MacCVS Pro that you're using. Grab MacCVS Pro
> 2.7d7.

WTF version of MacCVS Pro has such a flaw? (I hope not the one I'm using and
didn't know)

Comment 30

17 years ago
reply to conrad (2001-07-02 19:13):

I used version 2.7d6
(Assignee)

Comment 31

17 years ago
2.7d6 is afflicted, fixed in 2.7d7. The bug only happens if a file has mixed 
linebreaks in the CVS repository.

Comment 32

17 years ago
I believe that the only preprocessor macro which the build process needs to
define, uniquely for the static build, is ENABLE_STATIC_COMPONENT_LOADER.

Comment 33

17 years ago
Created attachment 41843 [details] [diff] [review]
first cut at MozillaBuildList.pm changes
(Assignee)

Comment 34

17 years ago
Created attachment 41869 [details] [diff] [review]
More complete XML projects patch

Comment 35

17 years ago
Status: I've landed on the branch, STATIC_BUILD_20010628_BRANCH. Paul Chen and I 
are in the process of ensuring that I landed correctly.

In order to do that, Paul:
1) get  XML::DOM for MacPerl (try "4G Server Storage:Tools:MacPerl XML.sit") If 
that doesn't work, talk to me -- the technique from "Comments From Simon Fraser 
2001-06-27 19:45" wasn't recreatable on my machine, although it certainly worked 
on his.

2) do a Debug build (optimized doesn't work yet). Suggested Prefs file to follow. 


Comment 36

17 years ago
Created attachment 43741 [details]
create XML, add targets, import XML, and build
(Assignee)

Comment 37

17 years ago
New XML::Parser module is available at:

http://usemacperl.webjump.com/downloads/XML-Parser-2.30-bin-Mac.tar.gz
(Reporter)

Updated

17 years ago
Depends on: 90793, 93566
(Reporter)

Updated

17 years ago
Depends on: 90763
No longer depends on: 90793
(Reporter)

Comment 38

17 years ago
Gotten preliminary comparing results on mac startup time, cold boot went from 23
down to 18 sec, 20+% gain.  warm boot stayed at 11 sec on both builds.

Need to:
1) figure out landing plan
   what are the issues/bugs need to be sorted out before we land on mozilla??
2) make installer works with static build
3) fixup/make sure commercial build works

Steve, please fill in all missing details we need in this bug, thanks!

Comment 39

17 years ago
cathleen - this performance improvement is with the static build already broken
up into components like the win32 build, right?  I just want to be sure we think
the gain will stay with us before we start hacking the build system.  Thanks!
(Assignee)

Comment 40

17 years ago
No. The mac static build is currently monolithic, apart from JS, NSPR, XPCOM, 
XPInstall and some runtime libs.

Comment 41

17 years ago
Landing Plan/issues:

Known bugs on tip of branch:
1) NS_GET_MODULE implementation of nsLocaleModule.cpp is almost certainly wrong 
(it links , but logic is almost certainly wrong). We need to know what we're 
doing before landing (Bug #93556)
    suggestion: either current owner or us should eyball currrent changes; ask 
owner how we test it; get reviewed.
2) probable resource-related problems: cursor bits are sometimes mangled; "Save 
AS" isn't working; printing seems broken.

Landing issues:
1) what is the official list of libs that should remain shared? 
(JavaScript.shlb, xpcom.shlb, and NSPR20.shlb are good-to-go; what about 
libreg.shlb?, others? NSRuntime.shlb adn NSStdLib.shlb should probably be taken 
out.)
2) do we check in only 2 .mcp's (the new StaticMerg.mcp and the edited 
apprunner.mcp) and let scripts recreate new static targets); 
OR also overwrite most of the other .mcp's with new static targets.

    PRO for checking in only two .mcp files: it makes landing easier
    CON for checking in only two .mcp files: it makes more difficult, fixing 
cases where the static build needs different (fewer) files than the shared build 
(for the first of many possible examples this: see next issue, where we may have 
to resolve dupicate symbol diagnostics by removing some object files)
        Since for the static build, the build scripts clone the set of files 
from the shared build; if we want different set of files, then special knowledge 
must be put into the build scripts)

    
    CON for checking in many .mcp files with new targets: penalizes everybody 
doing old-style build (by size and speed)(on pull and opening of project)
   
    Action Item: raise w/ macdev on Monday Aug 6th.

3) do we check-in apprunner.mcp with (prefs: "ignore duplicate symbol linker 
warnings" (only) for static targets)?
    suggestion: OK to check-in , but for the longer term it should be "off"
4) do we check merge trunk into branch first, or not?
    Action Item : look at changes to apprunner
    suggestion: decision in part, depends on how complicated landing is, which 
depends greatly on the decision for Landing Issue#2.

5) make sure installer works

6) make sure commerci

Comment 42

17 years ago
My Bad -- the NS_GET_MODULE bug for nsLocale is Bug#93566

Comment 43

17 years ago
Here's an overview of all the files which have been changed (or added), in order 
to make the static build work. For convenience, I have grouped them together in 
light of the gerneal reason why they were changed (or added). This grouping is 
only suggestive (some files were changed for more than one reason), but I 
believe that the list of files is complete.

build system stuff:
        BuildUtils.pm
        CodeWarriorLib.pm
        Moz.pm
        MozillaBuildList.pm
        ProjectXML.pm           // <---- new file
        MozillaBuildFlags.txt
        
projects changed to fix access paths, to fix build errors
        expat.mcp
        gifdecoder.mcp
        jpgdecoder.mcp
        libutil.mcp
        LiveConnect.mcp
        mngdecoder.mcp
        png.mcp
        txtsvc.mcp
        ucvja.mcp
        ucvko.mcp
        ucvtw2.mcp

high-level Projects, and related headers (like Prefix files)
        apprunner.mcp
        StaticMerge.mcp         // <---- new file
        apprunnerDebug.Prefix   // <---- new file
        apprunner.Prefix        // <---- new file
        apprunnerConfig.h       // <---- new file
        DefinesMozilla.h

change XPCOM registration, and change NS_GET_FACTORY implementation to 
NS_GET_MODULE
        nsGfxModule.cpp         // <---- new file
        nsLocaleModule.cpp      // <---- new file
        nsWidgetModule.cpp      // <---- new file
        gfx.mcp
        locale.mcp
        widget.mcp
        nsSetupRegistry.cpp
        nsStaticComponents.cpp  // <---- new file
        xpcomPPC.mcp
        xpcomConf
(Assignee)

Updated

17 years ago
Depends on: 94221, 94372, 94373

Comment 44

17 years ago
Verified security functionality by going to the `https://www.verisign.com' site.

On the branch, I checked in cryptoComponent.mcp, mailnewsComponent.mcp, and 
MozillaBuildList.pm changes which enable this functionality.

Comment 45

17 years ago
Comparison of nsStaticComponents.cpp: generated during unix build, vs. tip of 
mac static build branch.

1) there were references for mailnews and crypto in the unix version. Was I 
wrong to be surprised to see them still there?
	MODULE(NSS),                 // security: taken out of mac version
	MODULE(PKI),                 // security: taken out of mac version
	MODULE(nsMsgBaseModule),     // mailnews: taken out of mac version
	MODULE(nsMsgDBModule),       // mailnews: taken out of mac version
	MODULE(nsMsgNewsModule),     // mailnews: taken out of mac version
	MODULE(local_mail_services), // mailnews: taken out of mac version
	MODULE(nsMimeEmitterModule), // mailnews: taken out of mac version
	MODULE(nsVCardModule),       // mailnews: taken out of mac version
	MODULE(mime_services),       // mailnews: taken out of mac version
	MODULE(nsMsgComposeModule),  // mailnews: taken out of mac version
	MODULE(IMAP_factory),        // mailnews: taken out of mac version
	MODULE(nsAbModule),          // mailnews: taken out of mac version
	MODULE(nsImportServiceModule),// mailnews: taken out of mac version
	MODULE(nsTextImportModule),  // mailnews: taken out of mac version
	MODULE(nsAbSyncModule),      // mailnews: taken out of mac version
	
2) there was a reference in unix, which was never in the mac static build. (I 
suppose I should check that the build option `options transformiix' works) 
    MODULE(TransformiixModule),// <---- new to mac prototype
    
3) 5 references from unix, were in the base mac static source, but commented out 
during when engineering the static build, for various reasons (among them, I 
think, the the module boundaries might have been different on mac, and so some 
functionalty was in fewer modules on the mac).
Also, there are 2 names on the mac branch, which are not present on the unix 
branch.

	MODULE(nsGtkTimerModule), // commented out in mac prototype
	MODULE(nsGfxPSModule), // commented out in mac prototype
	MODULE(nsPPMDecoderModule), // commented out in mac prototype
	MODULE(nsWidgetGTKModule), // commented out in mac prototype
	MODULE(XRemoteClientModule), // commented out in mac prototype

// missing in unix, present on mac prototype: MODULE(nsJarModule),
// missing in unix, present on mac prototype: MODULE(nsWidgetModule),

In at least the widget case (nsWidgetModule vs. nsWidgetGTKModule), I think this 
is due to a difference in mac naming conventions.

I'll attach the unix version of nsStaticComponents.cpp, edited with my c++-style 
com

Comment 46

17 years ago
Created attachment 45871 [details]
nsStaticComponents.cpp gererated during unix build
(Assignee)

Comment 47

17 years ago
Created attachment 46128 [details] [diff] [review]
Diff of build script changes against the trunk
(Assignee)

Comment 48

17 years ago
Created attachment 46129 [details] [diff] [review]
Diff of static build script changes, against the trunk
(Assignee)

Comment 49

17 years ago
Oops, sorry for the double attachment. peterv, please review attachment 46129 [details] [diff] [review]. 
scc, an sr= would be super too.

Comment 50

17 years ago
I have some fairly serious surgery to do on mozilla/intl/locale; see bug 94831.
I'm going to try to land this in the next day or so, and this should get the
locale stuff working right on all platforms.
Pfew, what a patch. r=peterv.

+        if ($target =~ /(.+).shlb$/)        # if this is a shared lib target
+        {
+            my $target_base = $1;
+            my $static_target = $target_base.".o";

Are our targets always named "foo.shlb"? That's a must after this change, no?
(Reporter)

Comment 52

17 years ago
we really need to land all changes by end of this week.
what's the status right now?
Target Milestone: --- → mozilla0.9.4

Comment 53

17 years ago
Status Right Now:

On my machine, I've got the tip of the trunk (as of yesterday evening), merged 
with the tip of the static branch.

From this source, the shared lib version built. Since then, we are building the 
static version, and fixing any problems that we run into. It is building right 
now.

When this is done, I'll have to go back and prove that the shared lib build still 
works, in light changes made since yesterday evening.

Comment 54

17 years ago
Created attachment 47067 [details]
more detailed description of changes for review
+
	    if (! $main::options{"static_build"})
+
	    {
            
BuildOneProject(":mozilla:embedding:browser:powerplant:PPBrowser.mcp",         
  "PPEmbed$D",  0, 0, 0);


This isn't cool just to punt on this in a static build. Why doesn't it work?
What needs to be done to make the embedding sample work with the static build? I
would imagine that embedding clients will want to use static builds so the
embedding samples (all platforms) need to work with this.

Comment 56

17 years ago
If you check in mozilla/xpfe/bootstrap/nsStaticComponents.cpp and
mozilla/modules/staticmod/nsMetaModule_[mail|crypto].cpp, you will break the
static build on Win32 and Unix: there are different sets of modules compiled on
different platforms (e.g., nsGfxGTKModule, which we use on Unix to talk to GTK).
Please don't do that.
(Assignee)

Comment 57

17 years ago
jfrancis gave r=jfrancis
I give sr=sfraser on these changes.

Comment 58

17 years ago
a=asa on behalf of drivers.
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 59

17 years ago
Due to my taking over the JavaScript group, cathleen has asked sfraser to assume
responsibility for this bug.
Assignee: thesteve → sfraser
(Assignee)

Comment 60

17 years ago
Boing.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Comment 61

17 years ago
To 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Comment 62

17 years ago
->0.9.9
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Blocks: 127253
Keywords: topembed
(Assignee)

Comment 63

17 years ago
Need to get a test build for QA to do some perf tests.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla1.0
(Assignee)

Comment 64

17 years ago
We decided that this was not worthing doing for 1.0.
Target Milestone: mozilla1.0 → mozilla1.1alpha

Updated

17 years ago
Keywords: topembed → embed, topembed-
(Assignee)

Comment 65

17 years ago
Created attachment 79524 [details] [diff] [review]
Current state of my build scripts. With some MakeALias hacking, this should almost work.

Attaching snapshot of my current scripts. Patch is not a final patch.
Attachment #35897 - Attachment is obsolete: true
Attachment #35899 - Attachment is obsolete: true
Attachment #36147 - Attachment is obsolete: true
Attachment #36149 - Attachment is obsolete: true
Attachment #36155 - Attachment is obsolete: true
Attachment #40600 - Attachment is obsolete: true
Attachment #41843 - Attachment is obsolete: true
Attachment #41869 - Attachment is obsolete: true
Attachment #43741 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #46128 - Attachment is obsolete: true
Attachment #46129 - Attachment is obsolete: true
Attachment #47067 - Attachment is obsolete: true
(Assignee)

Comment 66

16 years ago
Not applicable since we're going to Macho-O
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Summary: make mac static build → make mac CFM static build

Comment 67

16 years ago
v wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.