Closed Bug 158729 Opened 22 years ago Closed 21 years ago

nmake removal breaks the installer


(SeaMonkey :: Build Config, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: dprice, Assigned: dprice)




(5 files, 1 obsolete file)

I can't create a win32 installer when I've built a tree with the gmake system

/mozilla/xpinstall/wizard/windows/build/ fails with the error...

Path not found
ccing the world and taking a look at the problem.
Blocks: 158528
Two things so far.  

First 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...

DIRS    += nsztool

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

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  It isn't coping the wildcard entries defined
in packages-win to the stage directory.  I run 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
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 and  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 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 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/  Otherwise (9x, ME, XP), I believe it gets set to WIN95.

Thanks. :)

The changes in my patch are in xpinstall/wizard/windows/builder/  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 and


But this only fixes one of a handful of problems, right?  (Also, this impacts
some documentation I'm doing for the site.)
Attachment #92331 - Flags: review+
Attached patch complete fixSplinter Review
This patch supports both nmake and gmake built trees.  It corrects the use of as well.  We had to move the stage directory because it was confusing

There will be a second patch for the netscape side.  But right now that's still
broken.  ns/ needs to be able to pull the right shelf directory based
on the platform.  I've asked for help to figure it out.
Attachment #92331 - Attachment is obsolete: true
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 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 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.

Attachment #93816 - Flags: review+
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 pull all of shelf for everyone

Attachment #93816 - Flags: superreview+
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'' 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...
         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

  Error: perl e:\mozilla_src\mozilla\stage

This does not work for me because I have:
in my mozconfig

also path to 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
I changed the paths carefully 

set MOZ_OBJDIR=path to your objdir as set in mozconfig
(for me it's f:\mozsrc\mozilla\obj-i586-pc-msvc)

run perl

installer in f:\mozsrc\mozilla\obj-i586-pc-msvc\dist\install
After reading comment 8 I ran make in the nsztool directory, then ran
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 and 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

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\ change

Attachment #95341 - Flags: review+
Comment on attachment 95341 [details] [diff] [review]
xpinstall\wizard\windows\ change

gmake it so, (superfluous sr=leaf)
Attachment #95341 - Flags: superreview+
Comment on attachment 94384 [details] [diff] [review]
fix when MOZ_OBJDIR set in mozconfig

This looks good.  We'll need to do the same thing in
Attachment #94384 - Flags: review+
Depends on: 164941 & friends were fixed in bug 162079.
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.5alpha
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.