Right now, nmake -fclient.mak pull_layout nmake -fclient.mak build_layout is hosed because of dependencies that hyatt and I added from netlib into RDF. We need to #ifdef this. Karnaze is mad as hell and he's not going to take it any more.

Okay, BUILD_DIST is what's broken. Here's how I suggest we fix it for now (because nobody ever really builds DIST by itself): Index: client.mak =================================================================== RCS file: /cvsroot/mozilla/client.mak,v retrieving revision 3.43 diff -c -r3.43 client.mak *** client.mak 1999/04/05 22:18:34 3.43 --- client.mak 1999/04/07 22:34:52 *************** *** 137,154 **** build_layout: @cd $(MOZ_SRC)\mozilla\. set LAYOUT_DIRS=1 nmake -f makefile.win all ! build_dist: ! @cd $(MOZ_SRC)\mozilla\. ! set DIST_DIRS=1 ! nmake -f makefile.win all ! clobber_dist: ! @cd $(MOZ_SRC)\mozilla\. ! rd /s /q dist ! set DIST_DIRS=1 nmake -f makefile.win clobber_all clobber_layout: --- 137,155 ---- build_layout: @cd $(MOZ_SRC)\mozilla\. + set DIST_DIRS=1 set LAYOUT_DIRS=1 nmake -f makefile.win all ! #build_dist: ! # @cd $(MOZ_SRC)\mozilla\. ! # set DIST_DIRS=1 ! # nmake -f makefile.win all ! #clobber_dist: ! # @cd $(MOZ_SRC)\mozilla\. ! # rd /s /q dist ! # set DIST_DIRS=1 nmake -f makefile.win clobber_all clobber_layout:

Doh! There's more to it than that... It looks like a bunch of modal dialog stuff that landed last night _also_ depends on the outside world (appshell, no less). So this is really starting to be screwed up. Fixing this quickly is beyond my humble means.

I'm presuming that the chrome: URL stuff can move out of netlib when the new netlib comes around. I implemented javascript: URLs outside netlib using a poor man's pluggable protocol hack, but that code is broken now, so I don't know if it's the right way to do it anymore. We need to discuss the modal dialog issue. This just ain't right.

Actually, the modal dialog stuff I checked in last night does _not_ necessarily depend on appshell, or anything else outside. I deliberately did not wire up the UI portion pending conversations with UI-saavy people. Yes, discussion is in order, but what I left un-implemented is the very thing that needs further discussion.

Spence: you did introduce a build-time dependency on _header files_ that are only exported if you build in the client dirs (even though you never actually do the instantiation at runtime). That's the problem that people are seeing.

What dependency is it that's screwing up people? I was trying to be particularly careful about that ... Let me know, and I'll fix it.

The (modal dialog) dependency is in mozilla/network/module/nsStubContext.cpp, #including nsAppShellCIDs.h.

nsStubContext.cpp ... ahh, I meant to clean that up. You'll notice that particular file is quite a mess. It's the ugly glue for the moment. The could that _would_ have depended on that is actually ifdef'd out right now; the include of nsAppShellCIDs.h is superfluous. There is real nastiness to figure out in wiring things up though ...

Sheesh. Has this _ever_ worked? Spence gave me a fix for the modal dialog bustage. Now I'm broken in forms with wallet stuff (nsFormFrame.cpp: "nsIWalletService.h, no such file or directory"). As much as I'd like to help, it looks like there are a _lot_ of unfortunate dependencies from core raptor to client. I am really not feeling like I want to be the guy that fixes them all. Especially if raptor standalone is not going to be tinderboxed.

Something doesn't sound right. If you are building layout, then there shouldn't be any dependency from core raptor to wallet stuff. Yes, there is an include of nsIWalletService.h in nsFormFrame.cpp but that is ifdefed by ClientWallet and/or SingleSignon. And neither of these should be turned on for the raptor-only build; they are on for the full browser build and then there is a dependency which we know is bad and plan on removing as soon as Karnaze comes up with an appropriate api for wallet to use. To see where ClientWalled/SingleSignon is disabled in the raptor-only build, look for MOZ_NO_WALLET_HACK in client.mak and in config.mak.

Okay, this was bogus. Turns out raptor pulls and builds all this stuff anyway. Or maybe it was valid and I fixed client.mak. I can't remember. Anyway, marking as fixed, 'cause nobody has complained for a while.

It's still a hassle. I can't build just Raptor by doing a nmake -f client.mak build_dist build_layout. In either case, the dependency still needs to be removed and, presumably, will be some time after the new netlib comes around, right?

cyeh, vidur: see the above diffs. would this be an acceptable way to fix the problem until N2 happens? Basically, instead of doing nmake -fclient.mak build_dist build_layout (which attempts to do a export/libs/install phase thru the dist dirs, and then an export/libs/install phase through the layout dirs), you'd just type: nmake -fclient.mak build_layout (which does export/libs/install through the union of the dirs). Recall the problem is that netlib (which is built in the "dist" phase) is depending on a header file in RDF (which is exported from "layout" phase).

this seems like the least of all evils. probably should send an e-mail message to raptor@netscape.com and let them know about the build procedure changes.