'nuff said.

for information on how the replacement works see: http://www.mozilla.org/build/win32.htm

Brian, your link doesnot work.

oo! oo! I found one. Where's my tequilla? ;) Check out 158729

http://www.mozilla.org/build/win32.html

It seems that svg doesn't build I've set MOZ_SVG=1 in my nmake build and I had to remove it so that I can build with GNU make Is this a known bug ?

you need "ac-add-options --enable-svg" in the .mozconfig and it should work

How is project creation and debugging supposed to work when client.mak goes away? The debugging FAQ directions at http://www.mozilla.org/build/win32- debugging-faq.html rely on client.mak.

the only reference to client.mak is: You do this by selecting File > Open Workspace... and opening client.mak. Visual C++ compains that it cannot read this project, and you can ignore this. so more than likely, you just select client.mk - it still won't be able to read it, and you continue to ignore it. someone should just test this, and update the doc.

mozilla/client.mak & mozilla/makefile.win have been removed. more to come later.

Here's the list of makefile.win that still need to be converted to Makefile.in and added to allmakefiles.sh. Most of them are module specific test dirs. The makefile.win files under resources/, content/ or locale/ are leftovers from the old pre-jar method of packaging chrome and need no Makefile.in equivalent.

Comment on attachment 94741 [details] List of makefile.wins to remove r=pavlov i was wondering why these were still in the tree...

Not sure if this is part of this bug, but since these messages only appear when using gmake..... Should .lib, .exp, .res and a few others be added to the .cvsignore files to prevent these messages when checking out? cvs -q -z 3 co -P -r NSPRPUB_PRE_4_2_CLIENT_BRANCH mozilla/nsprpub ? mozilla/nsprpub/lib/ds/plds.res ? mozilla/nsprpub/lib/ds/plds4.dll ? mozilla/nsprpub/lib/ds/plds4.exp ? mozilla/nsprpub/lib/ds/plds4.lib ? mozilla/nsprpub/lib/ds/plds4_s.lib ? mozilla/nsprpub/lib/libc/src/plc.res ? mozilla/nsprpub/lib/libc/src/plc4.dll ? mozilla/nsprpub/lib/libc/src/plc4.exp If this needs doing I'll volunteer to make the patch(es) if no-one else is working on it

There is a test to make sure the libical library is installed for building calendar at: http://lxr.mozilla.org/seamonkey/source/configure.in#3043 This test is not a valid test on a windows machine. So building using --enable-calendar with gmake in windows stops at that test. Note: ical can now be built on windows with gmake which will then provide ical.dll for calendar to link against. I suggest removing that test for now or making it specific to Linux builds

My previous comment has an out-of-date link. Here is what I'm talking about: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=configure.in&root=/cvsroot&subdir=mozilla&command=DIFF_FRAMESET&rev1=1.947&rev2=1.948 Also a bug has been filed on calendar about this: Bug 178798. Adding dependancy.

This is long done. Calendar dependencies will have to be handled in a separate bug as it sounds like we just flopped back to requiring the in-tree version of libical instead of an external version.