156577 - Produce a mozilla.org MRE

Status: VERIFIED DUPLICATE of bug 163689

(Core Graveyard :: Embedding: APIs, defect, P2)

Description

[Doug Turner (:dougt)]

make mre builds available.

Comment 1

[Chak Nanga]

Doug : Thanks for filing this bug!

I think all we need to do here is to do an "nmake -f makefile.win mre" in the
embedding/config dir - similar to the "regular" nightly embedding distributions
we already make.

Do you know how/who does the nightly embedding builds...thanks

Comment 2

[Doug Turner (:dougt)]

Chak, that is only part of the problem.  The bigger part of the story is getting
an installer.  Maybe we can use the same installer that mozilla uses for their
client?  

Comment 3

[Chak Nanga]

Doug/Leaf, I'm thinking of proceeding in the following two pronged approach:

1. Start doing nightly MRE builds by doing make as i describe above. We need to
zip up and push the "mre" dirs produced by the make process into a location
similar to what we're doing with nightly embedding distributions. Leaf : Can you
please let me know who setup the embedding nightlies?

2. Slap an installer on top of the mre nightlies produced in step 1 above.
Doug/Leaf : Do you know who does the Mozilla installers now?

Comment 4

[Daniel (Leaf) Nunes]

the embedding nightlies were set up by me, and they are produced by doing the
old make in embed and pushing up the resulting zip file (i'm pretty sure the
make creates the zip for me, but i'd have to doublecheck).

I'll take this bug and start working on it probably having it ready just after
1.1b ships.

Comment 5

[Chak Nanga]

Hi Leaf : Thanks for taking this bug.

Just to clarify, when you make mre it'll create the following two directories in
dist:
           mre
           mre_app_support

We need to zip up both of these directories into a single zip file as suggested
by dougt to me(over an IM session earlier today).

Comment 6

[Doug Turner (:dougt)]

Also, include the SDK directory.

Comment 7

[Chak Nanga]

Doug : Does the SDK dir which you're planning on including contain all the files
required for an embeddor to embed Gecko i.e. .lib's, .h's, .idl's etc?

Comment 8

[Doug Turner (:dougt)]

your right.  no sdk..


sdk should contain the mre, not the other way around.

Comment 9

[Daniel (Leaf) Nunes]

ok, changes made to automation to include mre and mre_app_support in
mre-win32.zip which will show up starting with the latest windows builds today
hopefully.

If this isn't the case monday, feel free to re-open.

Comment 10

[Chak Nanga]

mre-win32.zip's are showing up in the nighthly builds, thank you!

However, i noticed the following (empty) dirs are not packaged up under
mre_appsupport:
   components
   plugins

"make mre" does generate these directories, but, it looks like they're being
ignored as part of the zip packaging step?

We want those directories there so that embedding customers can simply copy
their app specific components and plugins into these empty directories. 

Comment 11

[Daniel (Leaf) Nunes]

ok; there's actually a problem with the build rules for those directories
(depend builds fail, because mkdir fails when trying to create an existing
directory). I'll attach a patch for that. I'll also fix the zip command to zip
even empty directories.

Comment 12

[Daniel (Leaf) Nunes]

Attachment: check for existence of the directories before mkdir'ing them

this should fix the 8am depend builds (which die when trying to make the mre).

Comment 13

[Chak Nanga]

Comment on attachment 92948 [details] [diff] [review]
check for existence of the directories before mkdir'ing them

r=chak

Looks good to me...thanks

Comment 14

[Daniel (Leaf) Nunes]

chak, i think it's your unzip client that is not uncompressing the directory
entries; if i fetch the .zip file, and run unzip -l on it, i see:

        0  07-26-02 05:55   mre_app_support/plugins/
        0  07-26-02 05:55   mre_app_support/components/


Some winzip clients, by default, don't uncompress empty directories (we had this
problem with winzip and the mozilla source tarballs, but with 0-length files).

I think you can fix this client side; if not, we can modify the rules to create
dummy file entries in the directories and see if that works better.

Comment 15

[Chak Nanga]

Hi Leaf : You're correct - it's my version of winzip which's screwing it up.
Using unzip -l i see the empty dirs.

Since most Windows users use winzip they'll definitely run into this. Your idea
of creating dummy (README ?) files in those dirs sounds like a great idea. We
can later add content to those README files, if needed...thanks

Comment 16

[Aki Sasaki]

*** This bug has been marked as a duplicate of 163689 ***

Comment 17

[Charles Rosendahl]

verified