this gets handled for windows as a separate release step (a target in mozilla/Makefile), which explains why the embed-win32.zip files are so much smaller than the embed-i686-pc-linux-gnu.tar.gz files. I have a patch that will strip the dist/Embed .so|dll files if they have not yet been stripped by the time the embedding directory is created.
Created attachment 126412 [details] [diff] [review] after the embed copy is done, strip binaries if we have a STRIP defined.
Comment on attachment 126412 [details] [diff] [review] after the embed copy is done, strip binaries if we have a STRIP defined. Shouldn't that be ENABLE_STRIP?
Attachment #126412 - Flags: superreview?(seawood) → superreview-
I would use ENABLE_STRIP, and turn it on in the release builds, but we need to keep the binaries in dist from getting stripped (they need to be put onto the talkback server intact). I decided to check for STRIP just to make sure that a strip was defined (i'm guessing it isn't on windows). The other option is to push this to the release automation, but i thought it would make more sense in the embedding/config Makefile, since it's only really used for making releases anyway. If you feel like this is too inflexible (someone may want a debug dist/Embed?)... i can push it out to the release automation to strip the dist/Embed directory.
STRIP is always defined. If an actual strip binary doesn't exist, then it merely sits as 'echo not_strip'. Maybe that should be changed. I think it should be pushed into the automation or use a more appropriate variable that's only set by the automation. Other embeddors use embedding/config/ and I'm not sure if they always want the embedding files to be stripped.
Priority: -- → P1
Target Milestone: --- → mozilla1.5beta
dist/Embed should be dead or at least actively dying. WONTFIX
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.