Add GRE installer to the build process

VERIFIED FIXED in mozilla1.2beta


Core Graveyard
Installer: GRE
16 years ago
7 years ago


(Reporter: Curt Patrick (gone), Assigned: Aki Sasaki)


Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment, 5 obsolete attachments)



16 years ago
Need to start delivering nightly builds of the mre installer package to  Initially we'll just deliver a blob installer (self-extracting
exe) but evenetually I think we'll have to deliver a stub installer also.

I've got a new directory and one other new file which I need to check in.  Then
Aki can do whatever magic is needed to plug this into the nightly build process.

Comment 1

16 years ago
I checked in the following files as "Not (yet) in build":

- mozilla/xpinstall/packager/pkgs-mre-win
- mozilla/xpinstall/packager/win_mre/ (and all the files which it contains)
- mozilla/xpinstall/wizard/windows/builder/

Aki, to add the mre installer to the build process you need to call
mozilla/xpinstall/packager/win_mre/ in exactly the same way that
mozilla/xpinstall/packager/winows/ is currently called.  The result
will be that the directory mozilla/dist/inst_mre will be created and filled with
mre installer files.  For the time being the only file which needs to be
delivered to with the nightly builds is

So I believe we need for Chris to review what I've checked in and give us the
thumbs up before we actually plug this into the nightlies?

Comment 2

16 years ago
Actually, I guess the remaining work is on Aki.  Let me know what help you need
from me to finish this up.
Assignee: curt → asasaki

Comment 3

16 years ago
We need to expand this bug to cover adding an installer for mfcembed also, which
will be used to test the mre.  So I'll create that installer and the scripts and
such to build it.  These two installers (the mre installer and the mfcembed
installer) need to replace the corresponding zip files which release is
currently delivering with nightly builds, i.e. and

Chak, you said that the mfcembed installer will need all of the mre support
files and two other files, mfcembed.exe and what else?

So the steps required to close this bug will be:

1) Curt create mre installer and build scripts. (done)
2) Aki plug in mre installer build and deliver to with nightlies.
3) Aki stop delivering
4) Curt create mfcembed installer and build scripts
5) Aki plug in the mfcembed build and deliver to with nightlies
6) Aki stop delivering

So at this point Aki can create a patch for Step 2 and I'm working on Step  4.

Comment 4

16 years ago
>>>>Aki stop delivering

Actually, there's not an The zip file we currently produce
is known as and we should _NOT_ stop delivering this as there
are a lot of non-MRE users who depend on it.

>>>Chak you said that the mfcembed installer will need all of the mre support
files and two other files, mfcembed.exe and what else?

MfcEmbed installer needs :
1. All the files/dirs under mre_app_support.[Note that we do not want to keep
the dir name as mre_app_support - only the files/dirs under it copied to a user
specified location]
2. MfcEmbed.exe
3. mfcEmbedComponents.dll
4. A bat file to run mfcembed - say named as, runapp.bat.

Contents of runapp.bat:
@echo OFF
REM --------------------------------------------------------
REM Modify MRE_DIR below to match your MRE install location
REM --------------------------------------------------------
set MRE_DIR=c:\mre1.0 
set PATH=%PATH%;%MRE_DIR%;%MRE_DIR%\components
mfcembed.exe -console

Jud mentioned that it's really important that we plug the MRE and MfcEmbed
installers plugged into the nightly builds so QA can start testing it right away.

Comment 5

16 years ago
this looks like it's, not

is there a reason why we have a pkgs-mre-win instead of adding those files to

Comment 6

16 years ago
Correct about the  My mistake.

As for the packaging lists:  We are installer a completely independent set of
files from what packages-win lists, for a completely seperate installer. 
Packages-win is the set of file that goes into the Mozilla Windows installer,
pkg-mre-win is the set of files that goes into the MRE Windows installer. 
You'll note that windows\ uses packages-win whereas win_mre\
uses pkg-mre-win.

Comment 7

16 years ago
I've added the following for the mfcembed installer:

mozilla\xpinstall\packager\win_mfcembed\ (and a set of files)

As in the other cases, the nightly build process needs to launch
mozilla\xpinstall\packager\win_mfcembed\ appropriately and deliver the
resulting mozilla\dist\inst_mfcembed\sea\mfcembed-win32-installer.exe to

So, Aki, I think my part is now done.  Let me know if you need my assistance
with anything else.  The fans are clamouring to start getting this so I'll be
glad to do whatever is necassary to help make this happen.

(...and a reminder that, contrary to my listed steps above, we DO WANT TO KEEP
ON DELIVERING with the nightly builds.  I was mistaken on this

Comment 8

16 years ago
ok.  i can't find anywhere pertinent in mozilla or ns. =P is called by, which we use to do daily builds.
 however, i did a recursive grep under xpinstall for mre-win32-installer.exe and
i'm getting nothing.
can you double check this?

Comment 9

16 years ago
You probably don't need to do anything with, or the related and  These are specifically for developers to use.

I *think* you are on the right track with  I cannot find
a copy of that file in my tree, but I believe is the script that Release runs to
deliver then nightlies.  You probably want to add similar calls to the's for mre and mfcembed.  This should cause the two new
installers--i.e., mozilla\dist\inst_mre\sea\mre-win32-installer.exe and
mozilla\dist\inst_mfcembed\sea\mfcembed-win32-installer.exe--to be created.

Then somewhere in you should find something about
mozilla\dist\install\sea\mozilla-win32-installer.exe.  Whatever is currently
being done for that file we want to do for these two new installers as well.

Does that help?  Hopefully Leaf will get a chance to look at this bug later and
correct any misinformation above.  If we're still having trouble come Monday
I'll come up to MV and look at this with you.

Comment 10

16 years ago
right. however, as i said in my earlier comment, i can't find
mre-win32-installer.exe (string) in a recursive grep under xpinstall... did you
overwrite win_mre when you meant to add win_mfc?

right now the issue is will it work when i add the lines, meaning i need to make
sure the path and file names are right.  once i get this all straightened out, i
should be able to add it to on the build machine and give
it a test run.  then check in if it works.

Comment 11

16 years ago
I TOTALLY misread your previous comment.  You are right on the money.  Somehow I
managed to check in some of the mfcembed stuff over the mre stuff after I was
done testing mre.  Good catch.  You should be able to proceed now, although I'm
going to double check to make sure I didn't step on something else.

Comment 12

16 years ago
I did find one other small problem.  The scripts were assuming that the install
directories already existed.  I just checked in a fix for that.

This brought to mind something that you need to know.  Both of these new
installer builds assume that the mozilla installer has already been built so
they can grab necassary files from there.  Let me know if this presents any

Comment 13

16 years ago
Created attachment 96769 [details] [diff] [review] patch

this should do it.
*however* there is no builder/win_mfcembed directory... could you check this
once that's in i can try running this script on jebus after the trunk opens

Comment 14

16 years ago
Comment on attachment 96769 [details] [diff] [review] patch

Don't need to deliver the stub installers for now.  Might to hurt to just
comment lines out so we can just uncomment when someone suddenly decides they
are needed.

Also, I believe you need to make a call to , something like the

perl $ver $cwdDist\\stage $cwdDistWin\\inst_mre -aurl $inX
piURL -rurl $inRedirIniURL

for both pkgs-mre-win and pkgs-mfcembed-win, before the corresponding's will work.

Okay, I checked in packages\win_mfcembed.  I should say, I checked it in again.
 That explains the earlier wierdness we got with mfcembed files getting checked
in over mre stuff.  Somehow, cvs\Repository thought my mfcembed directory was
the mre.  That was screwing everything up!  I *think* I've got it all
straightened out now.

Comment 15

16 years ago
Created attachment 96882 [details] [diff] [review]
updated patch with pkgcp and no installer delivery

look better?
Attachment #96769 - Attachment is obsolete: true

Comment 16

16 years ago
Sorry, i don't understand all the build process details...but...

I just wanted to make sure that all we need are the mre installer and the
MfcEmbed installer in .exe formats. If you want to provide .xpi installers it's
fine but it's not a priority.

Comment 17

16 years ago
Sorry.  I was clear enough about what to deliver.  We do want the binary/blob,
but not the stub installer.  So it should look like:

+#    commenting mre/mfcembed stub installers out for now.
+#    # copy mre and mfcembed files
+    copy("mozilla\\dist\\inst_mre\\sea\\mre-win32-installer.exe",
+         "$delivery_dir\\mre-win32-installer.exe");
+#    copy("mozilla\\dist\\install\\stub\\mre-win32-installer.exe",
+#         "latest-$milestone\\mre-win32-installer.exe");
+    copy("mozilla\\dist\\inst_mfcembed\\sea\\mfcembed-win32-installer.exe",
+         "$delivery_dir\\mfcembed-win32-installer.exe");
+#    copy("mozilla\\dist\\install\\stub\\mfcembed-win32-installer.exe",
+#         "latest-$milestone\\mfcembed-win32-installer.exe");

Notice, also, that a couple of the above lines are trying to copy the mre and
mfcembed installer from the the install directory.  This must be changed to
inst_mre and inst_mfcembed.

The most important change, though, (I didn't spot this earlier), the calls to must point to the correct install folders (i.e., inst_mre and
inst_mfcembed) or we're going to step all over the mozilla installer big time. 
So the following, for mre: $xpistring $ENV{MOZ_SRC}\\stage $ENV{MOZ_SRC}\\mozilla\\dist\\install
-aurl $mozilla_ftp_url/$delivery_dir/windows-xpi

must be changed to: $xpistring $ENV{MOZ_SRC}\\stage
$ENV{MOZ_SRC}\\mozilla\\dist\\inst_mre -aurl

and ditto for mfc_embed

We are getting there, though.

Comment 18

16 years ago
Created attachment 96896 [details] [diff] [review]
adding sea installers back, changing install directories.

this one good to test?
Attachment #96882 - Attachment is obsolete: true

Comment 19

16 years ago
Looks like a winner to me.

Comment 20

16 years ago
I'm getting the following:

 Copying runapp.bat c:\builds\seamonkey\stage\mfcembed\bin
        1 file(s) copied.
The display version is: 1.1

 Verifying existence of required components...
           ok: c:\builds\seamonkey\stage\mre
copy "c:\builds\seamonkey\mozilla\xpinstall\packager\common\share.t" mre.templat
        1 file(s) copied.
The system cannot find the file specified.

 Making mre.xpi...
  adding: install.js (deflated 69%)

 mre.xpi done!
        1 file(s) copied.
The system cannot find the file specified.

 Error: copy c:\builds\seamonkey\mozilla\dist\inst_mre\..\install\xpcom.xpi c:\b
Sending c:\tmpmail.txt to cltbld-page
Subject:Fatal Error
Login name is
[JEBUS 2002-08-27-04-trunk] problem with win_mre in mozilla

[JEBUS 2002-08-27-04-trunk] problem with win_mre in mozilla


Comment 21

16 years ago
Created attachment 97105 [details] [diff] [review]
update to build embedding before attempting to do mre stuff
Attachment #96896 - Attachment is obsolete: true

Comment 22

16 years ago
Created attachment 97106 [details]
dist contents

died in the same place... it's install/xpi/ not install/ where you wanna look
for xpcom.xpi.	here's what the contents of dist look like on the machine, so
we can fix path probs.

Comment 23

16 years ago
You are quite right.  I forgot that the developer environment is different from
the build environment in that regard for debugging purposes.  The scripts are
fixed now.

Comment 24

16 years ago
we're in the middle of pushing right now, and there's an mre-win32-installer.exe
and mfcembed-win32-installer.exe (2002-08-29-08-trunk mozilla build)

should i check this in, or...?  do you want to verify the installers?  we're
gonna be gone till tuesday, but i'm pretty sure builds will keep going if i
change jebus at least.

Comment 25

16 years ago
I'm trying to verify the installers but i do not see mre-win32-installer.exe
or mfcembed-win32-installer.exe there.

I'm looking at

Comment 26

16 years ago
they're there.  takes a while to push from stage to ftp.

Comment 27

16 years ago
Ok, i'll wait for them to show up there and then do a quick test...thanks

Comment 28

16 years ago
If Chak gives a thumbs up, you've got my approval to check this in.

Comment 29

16 years ago
also, no changes to the build systems right before a weekend, per granrose. 
i'll check this in and update the build systems on tuesday.  meanwhile, we have
the installers from today's build.

Comment 30

16 years ago
Here's what i'm seeing:

1. I ran the mre-win32-installer.exe
2. Changed the install dir to c:\temp\mre and proceeded with the install
3. After the install was done all i see are the following in c:\temp\mre. The
MRE related files are not there.

    08/29/2002  03:48 PM             1,628 install_status.log
    08/29/2002  03:48 PM             1,458 install_wizard.log
    08/29/2002  03:48 PM    <DIR>          uninstall
               2 File(s)          3,086 bytes

Curt/Aki : Can you try it out to see if it works for you...thanks

Comment 31

16 years ago
Forgot to add this regarding the MRE currently sets the default
install path to "C:\Program Files\Mozilla\MRE\1.1" - we should have the version
number as "1.0".

Regarding the mfcembed-win32-installer.exe...The installer ran fine and it
_seems_ to have installed all the required files.

The main issue here is the default installation dir the installer presents. It
currently sets it to "C:\Program Files\Mozilla\MRE" - we want it to be
"C:\Program Files\Mozilla\MfcEmbed" or something like that.


Comment 32

16 years ago
we're using the mozilla version.  where should we get the 1.0 from?  i'd rather
not hardcode it in the build script.

Comment 33

16 years ago
We are going to need to add a version number variable into the scripts for MRE.
 It has to be tracked independent of Mozilla.

I'll look into the other problems Chak identified.

I think we should get this checked in and open bugs on problems we see.  We
should just hold off announcing that the installers are available until we've
got a good build in hand.

Comment 34

16 years ago
I checked into the problems which Chak identified.  All of them except the
version of mre were left overs from the problem I was having with cvs mixing up
my mre and mfcembed files.  This is really weird.  I've thought that I had this
straightened out a couple times now.  I *think* it is straight now.  The next
build Aki does should have these problems resolved.

Comment 35

16 years ago
reran the build.  should appear on ftp soon... everything but the version should
be fixed.  for the version, i think i'll just put in a flatfile with the version
number (1.0) somewhere in win_mre/ and read that in the build script.

Comment 36

16 years ago
Created attachment 97695 [details] [diff] [review]
update to include 1.0 version for mre/mfc

this should give mre and mfc a 1.0 version.
hardcoded, but the ns and moz versions are hardcoded also =P

if the current installers look good other than the version, this should be
Attachment #97105 - Attachment is obsolete: true
Attachment #97106 - Attachment is obsolete: true

Comment 37

16 years ago
looks like versions are still horked... it's reporting as "1.0." rather than
"1.0" (trailing dot).

what's the reasoning behind having a separate version from mozilla?

also, how does it look, otherwise?

Comment 38

16 years ago
MRE is a seperate product from Mozilla.  It is a collection of shared library
that other products can develop on top of.  For example, Mozilla may build a
release on one version of MRE, Netscape might build a release on the same or a
different version of MRE.  Mozilla may change versions without changing the
version of MRE it is using.  And, vice versa, Mozilla might want to use a
different version of MRE without changing the version of Mozilla (to take
advantage of security fixes in MRE, for example).

I'm tracking a problem with the MRE installer right now, but that doesn't have
anything to do with your scripts.  Have we got permission to check in your
script changes?  They don't have any impact on the mozilla build, do they?  So
it seems like we aught to be able to check them in.  But I'm having trouble
getting any feedback from drivers on my end.  Who do you need permission from
for changes to Release build scripts?

Comment 39

16 years ago
I always thought mozilla was supposed to be a developer product, not a consumer
product, so I can't imagine mozilla shipping a browser with a different version
MRE inside it.  If we have to have a separate version # for MRE and for the
browser, that will mean more version number hacking and release update
headaches.  I think we should keep the MRE version number the same as the
mozilla release.

cc'ing asa for his take.
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta

Comment 40

16 years ago
If it's just the version number that's holding up getting the nightly MRE builds
- then let's just make the MRE version number the same as the Mozilla version
number for the timebeing as Jon et al are suggesting.

We really need to get the nightly MRE builds into QA's hands for testing asap.

Comment 41

16 years ago
Comment on attachment 97105 [details] [diff] [review]
update to build embedding before attempting to do mre stuff

now the correct patch
Attachment #97105 - Attachment is obsolete: false

Comment 42

16 years ago
Comment on attachment 97695 [details] [diff] [review]
update to include 1.0 version for mre/mfc

no longer the correct patch
Attachment #97695 - Attachment is obsolete: true

Comment 43

16 years ago
we're already doing builds.  the patch just isn't checked in.  in comment #37 i
asked how it looked, and doesn't look like anyone's responded yet.  i'll replace
the script on jebus with the current patch (version corresponds with mozilla
version) today, and we'll have a general idea what it looks like with tomorrow
morning's build.

Comment 44

16 years ago
Chak is back (I think) today.  I'm intending to go over this with him and get
you some feedback.  The mre installer won't be 100% until I can get the engine
changes checked in (the trunk is frozen right now), but we can still get an idea
whether the build process is not working and complete.  Thanks, Aki.


16 years ago
No longer blocks: 167606, 167608

Comment 45

16 years ago
see bug 167795 for the latest and greatest.

Comment 46

16 years ago
the patch in bug 167795 is checked in.  closing this bug... any further changes
can go in that bug or a new one.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 47

16 years ago
sweet.  I see the checkin landed and a gre installer in this morning's trunk
directory on
Summary: Add MRE installer to the build process → Add GRE installer to the build process

Comment 48

16 years ago
And it works pretty darn good too :-) 

i tested the latest GRE installer and MfcEmbed installer and they both work great.

One minor thing we need to fix is the runapp.bat file(installed as part of the
MfcEmbed installation) it still refers to MRE and the old version number. Once
we get that fixed we can hand these off to QA. Curt's also investigating getting
rid of the bat file altogether.

thanks everyone for all the great work!


16 years ago
QA Contact: bugzilla → carosendahl

Comment 49

16 years ago
*** Bug 156577 has been marked as a duplicate of this bug. ***


16 years ago
Component: Installer → Installer: GRE

Comment 50

16 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.