Closed Bug 163689 Opened 22 years ago Closed 22 years ago

Add GRE installer to the build process

Categories

(Core Graveyard :: Installer: GRE, defect, P1)

Product:
Core Graveyard
Component:
Installer: GRE
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: curt, Assigned: asasaki)

References

Details

Attachments

(1 file, 5 obsolete files)

update to build embedding before attempting to do mre stuff
4.87 KB, patch
Details | Diff | Splinter Review
Need to start delivering nightly builds of the mre installer package to mozilla.org. 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.
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/build_mre.pl Aki, to add the mre installer to the build process you need to call mozilla/xpinstall/packager/win_mre/buildall.pl in exactly the same way that mozilla/xpinstall/packager/winows/buildall.pl 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 mozilla.org with the nightly builds is mozilla/dist/inst_mre/sea/mre-win32-installer.exe. 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?
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
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. mre-win32.zip and embed-win32.zip 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 mozilla.org with nightlies. 3) Aki stop delivering mre-win32.zip 4) Curt create mfcembed installer and build scripts 5) Aki plug in the mfcembed build and deliver to mozilla.org with nightlies 6) Aki stop delivering mfcembed-win32.zip So at this point Aki can create a patch for Step 2 and I'm working on Step 4.
>>>>Aki stop delivering mfcembed-win32.zip Actually, there's not an mfcembed-win32.zip. The zip file we currently produce is known as embed-win32.zip 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.
this looks like it's makeall.pl, not buildall.pl. is there a reason why we have a pkgs-mre-win instead of adding those files to packages-win?
Status: NEW → ASSIGNED
Correct about the makeall.pl. 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\makeall.pl uses packages-win whereas win_mre\makeall.pl uses pkg-mre-win.
I've added the following for the mfcembed installer: mozilla\xpinstall\packager\pkgs-mfcembed-win mozilla\xpinstall\packager\win_mfcembed\ (and a set of files) mozilla\xpinstall\wizard\windows\builder\build_mfcembed.pl As in the other cases, the nightly build process needs to launch mozilla\xpinstall\packager\win_mfcembed\makeall.pl appropriately and deliver the resulting mozilla\dist\inst_mfcembed\sea\mfcembed-win32-installer.exe to mozilla.org. 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 embed-win32.zip with the nightly builds. I was mistaken on this count.)
ok. i can't find build.pl anywhere pertinent in mozilla or ns. =P makeall.pl is called by build-verification.pl, 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? tx
You probably don't need to do anything with build.pl, or the related build_mre.pl and build_mfcembed.pl. These are specifically for developers to use. I *think* you are on the right track with build_verification.pl. 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 makeall.pl'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 build_verification.pl 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.
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 build-verification.pl on the build machine and give it a test run. then check in if it works.
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.
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 problems.
Attached patch build-verification.pl patch (obsolete) — — Splinter Review
this should do it. *however* there is no builder/win_mfcembed directory... could you check this in? once that's in i can try running this script on jebus after the trunk opens tomorrow...
Comment on attachment 96769 [details] [diff] [review] build-verification.pl 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 pkgcp.pl , something like the following: perl makeall.pl $ver $cwdDist\\stage $cwdDistWin\\inst_mre -aurl $inX piURL -rurl $inRedirIniURL for both pkgs-mre-win and pkgs-mfcembed-win, before the corresponding makeall.pl'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.
look better?
Attachment #96769 - Attachment is obsolete: true
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.
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 makeall.pl 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: makeall.pl $xpistring $ENV{MOZ_SRC}\\stage $ENV{MOZ_SRC}\\mozilla\\dist\\install -aurl $mozilla_ftp_url/$delivery_dir/windows-xpi must be changed to: makeall.pl $xpistring $ENV{MOZ_SRC}\\stage $ENV{MOZ_SRC}\\mozilla\\dist\\inst_mre -aurl $mozilla_ftp_url/$delivery_dir/windows-xpi and ditto for mfc_embed We are getting there, though.
this one good to test?
Attachment #96882 - Attachment is obsolete: true
Looks like a winner to me. r=curt
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 e 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 uilds\seamonkey\mozilla\dist\inst_mre Sending c:\tmpmail.txt to cltbld-page Subject:Fatal Error Login name is cltbld@netscape.com [JEBUS 2002-08-27-04-trunk] problem with win_mre makeall.pl in mozilla 2002-08-27-04 [JEBUS 2002-08-27-04-trunk] problem with win_mre makeall.pl in mozilla 2002-08-27-04 2002-08-27-04-trunk
Attachment #96896 - Attachment is obsolete: true
Attached file dist contents (obsolete) —
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.
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.
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.
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 ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-08-29-08-trunk/
they're there. takes a while to push from stage to ftp.
Ok, i'll wait for them to show up there and then do a quick test...thanks
If Chak gives a thumbs up, you've got my approval to check this in.
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.
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
Forgot to add this regarding the MRE installer...it 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.
we're using the mozilla version. where should we get the 1.0 from? i'd rather not hardcode it in the build script.
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.
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.
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.
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 good.
Attachment #97105 - Attachment is obsolete: true
Attachment #97106 - Attachment is obsolete: true
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?
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?
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
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 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 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
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.
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.
No longer blocks: 167606, 167608
see bug 167795 for the latest and greatest.
the patch in bug 167795 is checked in. closing this bug... any further changes can go in that bug or a new one.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
sweet. I see the checkin landed and a gre installer in this morning's trunk directory on mozilla.org.
Summary: Add MRE installer to the build process → Add GRE installer to the build process
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!
QA Contact: bugzilla → carosendahl
*** Bug 156577 has been marked as a duplicate of this bug. ***
Component: Installer → Installer: GRE
verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: