I can't create a win32 installer when I've built a tree with the gmake system /mozilla/xpinstall/wizard/windows/build/build.pl fails with the error... Path not found Y:\mozilla\dist\win32_d.obj

ccing the world and taking a look at the problem.

Two things so far. First build_all.pl does some work to find the location of dist. Then it has some code that appends either win32_d.obj or win32_o.obj onto the end of that path. I've got a patch that gets rid of that code. I'm assuming that we'll never see the win32_x.obj folders when we are in the gmake world. If that's not the case, then the code needs to change to handle 3 different dist directories. Second nsztool.exe wasn't build (mozilla/xpinstall/wizard/windows/nsztool) The makefile in mozilla/xpinstall/wizard/windows/ has this section of code... ifeq ($(OS_TARGET),WINNT) DIRS += nsztool endif I've got the environment variable OS_TARGET set to WINNT, but this isn't building. I suspect that isn't the right thing to do any more. Will I have to do something to my mozconfig file? Will we need to add something to the configurator? The installer that I made failed because psm.xpi was empty. Looks like I didn't have it set to build psm. rebuilding...

regus.xpi is also broken. It isn't being created with the bin/defaults directory. psm.xpi is fine though.

I'm having problems with pgkcp.pl It isn't coping the wildcard entries defined in packages-win to the stage directory. I run build.pl once, and loads of files are copied, but not the wildcard entries. The second time I run the script it fails almost immediately, unable to verify that any the files are in the stage directory.

Leaf, any thoughts on this? I thought that the nightly automation had already been switched to using gmake and the installers were built as well?

cls has the right of it; the nightly verification builds use gmake to do the build, and then use pkgcp.pl and makeall.pl to make the installer packages; the windows build automation has been fixed to find the files where they live; using MOZ_SRC and guessing where dist is. Anything hardcoded to use nmake-style objdirs is probably going to fail, so dprice's fixes to build.pl are probably good.

any ideas about the problems I'm seeing getting mozilla/xpinstall/wizard/windows/nsztool to build? my OS_TARGET environment veriable is set, but it still isn't building this directory? Am I doing something wrong?

OS_TARGET shouldn't be set in the enviornment. Per http://www.mozilla.org/build/win32.html section 2.2b, the only things that should be set in the env are MOZ_TOOLS & MOZCONFIG if you use a mozconfig file. If you are building on NT or 2k, OS_TARGET should set to WINNT in config/autoconf.mk. Otherwise (9x, ME, XP), I believe it gets set to WIN95.

Thanks. :) The changes in my patch are in xpinstall/wizard/windows/builder/build.pl Which according to ssu, are just there to make development easier and shouldn't really block anything from happening.

Comment on attachment 92331 [details] [diff] [review] patch to remove $distWinPathName from build.pl and build-static.pl r=curt But this only fixes one of a handful of problems, right? (Also, this impacts some documentation I'm doing for the mozilla.org site.)

This patch supports both nmake and gmake built trees. It corrects the use of pkgcp.pl as well. We had to move the stage directory because it was confusing pkgcp.pl There will be a second patch for the netscape side. But right now that's still broken. ns/client.mk needs to be able to pull the right shelf directory based on the platform. I've asked for help to figure it out.

I'm sure there's a better way to do this, but my makefile-fu isn't very strong. This will work. It will mean that anyone using client.mk to pull the shelf stuff (only the install team really) will get the entire ns/shelf instead of their platform specific half of it.

Comment on attachment 93816 [details] [diff] [review] hacky work around to make client.mk pull all of shelf for everyone WFM. Platform specific pull rules have the nasty side effect of getting missed whenever someone tags the tree from a single platform anyway. r=cls

Comment on attachment 93527 [details] [diff] [review] complete fix What's the advantage of using $(OS) instead of $(OS_TARGET) ?

For some reason the test ifeq ($(OS_TARGET),WINNT) was failing and I couldn't figure out why. So ssu suggested using OS=Windows_NT instead.

Comment on attachment 93816 [details] [diff] [review] hacky work around to make client.mk pull all of shelf for everyone sr=mscott

OS_TARGET sometimes returns CYGWIN_NT-5.0, not sure why. My cygwin make's version is: GNU Make version 3.79.1 Leaf couldn't figure out why either.

I pulled a new tree ~3 hours ago and rebuilt, but.... gmake worked fine in mozilla/xpinstall/wizard/windows but running ``perl build.pl'' in mozilla/xpinstall/wizard/windows/builder failed in the cygwin bash shell because it uses \\ instead of / I ran it in a DOS shell and it failed with: inspector.xpi done! Making uninstall.ini... done! 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. building self-extracting uninstaller (MozillaUninstall.exe)... 1 file(s) copied. 'e:\mozilla_src\mozilla\dist\install\nsztool.exe' is not recognized as an internal or external command, operable program or batch file. Error: e:\mozilla_src\mozilla\dist\install\nsztool.exe e:\mozilla_src\mozilla\dist\install\MozillaUninstall.exe e:\mozilla_src\mozilla\dist\install\uninstall\*.* Error: perl makeall.pl 5.0.0.2002080721 e:\mozilla_src\mozilla\stage e:\mozilla_src\mozilla\dist\install ftp://not.supplied.com ftp://not.supplied.com E:\mozilla_src\mozilla\xpinstall\wizard\windows\builder>

This does not work for me because I have: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ in my mozconfig also path to pkgcp.pl and friends should use {MOZ_SRC} but binaries are under {MOZ_OBJ_DIR}\dist, you have to distinguish them and can't assume that binaries are under {MOZ_SRC}\mozilla

quick hack I use MOZ_OBJDIR environment variable to distinguish beetween nmake and gmake build I changed the paths carefully usage: set MOZ_OBJDIR=path to your objdir as set in mozconfig (for me it's f:\mozsrc\mozilla\obj-i586-pc-msvc) run perl build_static.pl results installer in f:\mozsrc\mozilla\obj-i586-pc-msvc\dist\install

After reading comment 8 I ran make in the nsztool directory, then ran build.pl again. This time it worked. The resulting installer installed Moz correctly, however it failed to start with an error about "moz_art_lgpl.dll not found". It runs fine from dist/bin. Minor nit. In both build.pl and build_static.pl the message print "* A self-extracting installer has been built and delivered:\n"; print "*\n"; print "* $cwdDistWin\\install\\mozilla-win32-install.exe\n"; print "*\n"; is wrong. The filename is mozilla-win32-install*er*.exe. I've not made a patch for this as it will only confuse things; maybe someone can add it to their patch(es)?

ssu: ah! our cygwin uname checks are outdated. We don't have checks for CYGWIN_NT-5.x . I just opened bug 161725 to fix that. parish: it looks as though moz_libart_lgpl.dll isn't in our package manifests. Did you have the same problem with nmake builds or is this the first time that you enabled svg? balleysson: please open a separate bug on the lack of objdir support.

No, nmake builds have worked just fine for over a year (I *always* build the installer and then use it to install every build I make).

Doh! Ignore that last comment. I didn't have SVG enabled under nmake. Sorry for the misinformation.

Comment on attachment 95341 [details] [diff] [review] xpinstall\wizard\windows\makefile.in change r=cls

Comment on attachment 95341 [details] [diff] [review] xpinstall\wizard\windows\makefile.in change gmake it so, (superfluous sr=leaf)

Comment on attachment 94384 [details] [diff] [review] fix build_static.pl when MOZ_OBJDIR set in mozconfig This looks good. We'll need to do the same thing in build.pl

Build.pl & friends were fixed in bug 162079.