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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.2beta
People
(Reporter: curt, Assigned: asasaki)
References
Details
Attachments
(1 file, 5 obsolete files)
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.
Reporter | ||
Comment 1•22 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/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?
Reporter | ||
Comment 2•22 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
Reporter | ||
Comment 3•22 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. 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.
Comment 4•22 years ago
|
||
>>>>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.
Assignee | ||
Comment 5•22 years ago
|
||
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
Reporter | ||
Comment 6•22 years ago
|
||
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.
Reporter | ||
Comment 7•22 years ago
|
||
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.)
Assignee | ||
Comment 8•22 years ago
|
||
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
Reporter | ||
Comment 9•22 years ago
|
||
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.
Assignee | ||
Comment 10•22 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 build-verification.pl on the build machine and give it a test run. then check in if it works.
Reporter | ||
Comment 11•22 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.
Reporter | ||
Comment 12•22 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 problems.
Assignee | ||
Comment 13•22 years ago
|
||
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...
Reporter | ||
Comment 14•22 years ago
|
||
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.
Comment 16•22 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.
Reporter | ||
Comment 17•22 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 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.
Assignee | ||
Comment 18•22 years ago
|
||
this one good to test?
Attachment #96882 -
Attachment is obsolete: true
Reporter | ||
Comment 19•22 years ago
|
||
Looks like a winner to me. r=curt
Assignee | ||
Comment 20•22 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 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
Assignee | ||
Comment 21•22 years ago
|
||
Attachment #96896 -
Attachment is obsolete: true
Assignee | ||
Comment 22•22 years ago
|
||
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.
Reporter | ||
Comment 23•22 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.
Assignee | ||
Comment 24•22 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•22 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 ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-08-29-08-trunk/
Assignee | ||
Comment 26•22 years ago
|
||
they're there. takes a while to push from stage to ftp.
Comment 27•22 years ago
|
||
Ok, i'll wait for them to show up there and then do a quick test...thanks
Reporter | ||
Comment 28•22 years ago
|
||
If Chak gives a thumbs up, you've got my approval to check this in.
Assignee | ||
Comment 29•22 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•22 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•22 years ago
|
||
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.
Assignee | ||
Comment 32•22 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.
Reporter | ||
Comment 33•22 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.
Reporter | ||
Comment 34•22 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.
Assignee | ||
Comment 35•22 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.
Assignee | ||
Comment 36•22 years ago
|
||
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
Assignee | ||
Comment 37•22 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?
Reporter | ||
Comment 38•22 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•22 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•22 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.
Assignee | ||
Comment 41•22 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
Assignee | ||
Comment 42•22 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
Assignee | ||
Comment 43•22 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.
Reporter | ||
Comment 44•22 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.
Reporter | ||
Updated•22 years ago
|
Assignee | ||
Comment 45•22 years ago
|
||
see bug 167795 for the latest and greatest.
Assignee | ||
Comment 46•22 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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 47•22 years ago
|
||
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
Comment 48•22 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!
Assignee | ||
Comment 49•22 years ago
|
||
*** Bug 156577 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Component: Installer → Installer: GRE
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•