158729 - nmake removal breaks the installer

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[dprice (gone)]

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

Comment 1

[dprice (gone)]

ccing the world and taking a look at the problem.

Comment 2

[dprice (gone)]

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

Comment 3

[dprice (gone)]

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

psm.xpi is fine though.

Comment 4

[dprice (gone)]

Attachment: patch to remove $distWinPathName from build.pl and build-static.pl

Comment 5

[dprice (gone)]

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.  

Comment 6

[hacker formerly known as [e-mail]]

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?

Comment 7

[Daniel (Leaf) Nunes]

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.

Comment 8

[dprice (gone)]

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?

Comment 9

[hacker formerly known as [e-mail]]

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.

Comment 10

[dprice (gone)]

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 11

[Curt Patrick (gone)]

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

Comment 12

[dprice (gone)]

Attachment: complete fix

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.

Comment 13

[dprice (gone)]

Attachment: ns side of the fix

Comment 14

[dprice (gone)]

Attachment: hacky work around to make client.mk pull all of shelf for everyone

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 15

[hacker formerly known as [e-mail]]

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 16

[hacker formerly known as [e-mail]]

Comment on attachment 93527 [details] [diff] [review]
complete fix

What's the advantage of using $(OS) instead of $(OS_TARGET) ?

Comment 17

[dprice (gone)]

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 18

[Scott MacGregor]

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

sr=mscott

Comment 19

[Sean Su]

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.

Comment 20

[parish]

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>

Comment 21

[Bernard Alleysson]

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

Comment 22

[Bernard Alleysson]

Attachment: fix build_static.pl when MOZ_OBJDIR set in mozconfig

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

Comment 23

[parish]

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)?

Comment 24

[hacker formerly known as [e-mail]]

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.  

Comment 25

[parish]

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

Comment 26

[parish]

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

Comment 27

[dprice (gone)]

Attachment: xpinstall\wizard\windows\makefile.in change

Comment 28

[hacker formerly known as [e-mail]]

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

r=cls

Comment 29

[Daniel (Leaf) Nunes]

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

gmake it so, (superfluous sr=leaf)

Comment 30

[dprice (gone)]

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

Comment 31

[hacker formerly known as [e-mail]]

Build.pl & friends were fixed in bug 162079.