321471 - publish gecko 1.8.0 / firefox 1.5 gecko-sdk

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect, P2)

Description

[:Mook]

In the past, there have been relases of gecko-sdk along with Mozilla (Suite) releases.  The last such release was against Mozilla 1.8b1.  See gecko-sdk-* in the URL.

It appears that none of firefox, seamonkey, or xulrunner are now publishing sdks alongside their releases.  It would be useful to have them on the FTP server.

(The only way I know of right now to get the equivalent would be to build, say, firefox yourself and use the copy in /dist/sdk...)

Oh, and sorry but I wasn't very sure which component this would go in :)

Comment 1

[Reşat SABIQ (Reshat)]

I support this bug. It confused me, and slowed down the adapting of my extension to 1.5 by about a week. I assumed 1.7.12 was the latest SDK.
Thanks to mook and gavin answering my questions on #extdev i was made aware that 1.5 requires 1.8 SDK. I already had 1.5 built on Linux, so it wasn't an overhead. But i'll need it again on Windows, and it would be preferrable to just be able to download the SDK, rather than having to built 1.5 on Windows.

Comment 2

[Reşat SABIQ (Reshat)]

1.8b1 sdk from http://releases.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.8b1/ doesn't cut it, so i have to build firefox on Windows.

Comment 3

[Reşat SABIQ (Reshat)]

I probably wouldn't trust a build made by somebody else, but in case it's useful to somebody, here's the one i build w/ some help:
http://ultranet.tv/public/gecko-sdk-1.8-win32.jar

Comment 4

[Chase Phillips]

Darin: This is a process of gathering the dist/sdk directory and putting it in a zip/tgz/dmg file, then uploading to a nightly directory with the other files for release, right?

Comment 5

[Reşat SABIQ (Reshat)]

Even more important than nightly is to have it next to fx 1.5 downloads:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5/

I used to get it from mozilla downloads, but 1.8 stable isn't available, and that only options was gone. Only b1 is available, which didn't work for fx 1.5:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.8b1/

Comment 6

[Chase Phillips]

(In reply to comment #5)
> Even more important than nightly is to have it next to fx 1.5 downloads:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5/

I want the packages to be part of the nightly uploads so they can be grabbed easily for releases.

Comment 7

[Chase Phillips]

Darin/Bsmedberg: Is it likely or unlikely that the Gecko SDK built as part of 1.5.0.1 will be useful for 1.5 developers?

Cycles are slim to respin 1.5 but if it's the only way to fix this bug as stated (I defaulted to fixing it for future releases, instead) then I'll take another look at it from that angle.

Comment 8

[Reşat SABIQ (Reshat)]

Btw., i have builds of 1.5 source for Win32 and Linux (gcc4, 32-bit). But i didn't know if there is a specific process around posting the SDK, like building on a particular box, or using specific .mozconfig files, so i didn't try to get mine released. Let me know if i can help.

Comment 9

[Benjamin Smedberg]

The 1.8.0.1 SDK is fine and good.

Comment 10

[Darin Fisher]

> Darin: This is a process of gathering the dist/sdk directory and putting it in
> a zip/tgz/dmg file, then uploading to a nightly directory with the other files
> for release, right?

Right.

> The 1.8.0.1 SDK is fine and good.

We should have had a 1.8 SDK, and perhaps we should release one retro-actively.  For extension authors, using the SDK corresponding to the oldest release they wish to support is the rule-of-thumb, so we should IMO release an SDK that corresponds to FF 1.5.

Comment 11

[Reşat SABIQ (Reshat)]

Could someone point me to where nightly builds are? I'd like to check if there's an official build of the sdk there.

P.S. Also, an unrelated question: would the sdk use static (contained in sdk .lib) C and C++ run-times if the browser is build w/ static option enabled? 
I changed my extension build to dynamic, but now have a choice of installing 70 dlls on user machines, changing project to VC 6.0, or possibly linking against a staticly built sdk.

Comment 12

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 13

[Alex Vincent [:WeirdAl]]

(In reply to comment #9)
> The 1.8.0.1 SDK is fine and good.
> 

Where is it?

Comment 14

[Darin Fisher]

*** Bug 327293 has been marked as a duplicate of this bug. ***

Comment 15

[Darin Fisher]

per shaver, assigning this bug to preed.  we should publish SDKs.  this should be added as a step to whatever release process we have.

for firefox 1.0, chase just did this by hand.

Comment 16

[Robert Kaiser]

BTW, as a note, I have removed suite's SDK packaging from xpinstall/packager/Makefile.in back in bug 292268 as darin said in bug 292268 comment #13 that this should be no concern of SeaMonkey but done along with XULRunner.
Looking at the diffs from back then, packaging the SDK was really just a matter of tarring up dist/sdk as said here before.

Comment 17

[Darin Fisher]

Is there anything I can do to help get this fixed?

Today, alone, I had two people separately ask me about where they could get a Gecko 1.8 SDK from.  All I could do is point them at my unofficial builds.

bsmedberg: shouldn't this be a high priority item for xulrunner 1.8.0.1 ?

Comment 18

[Robert Kaiser]

Darin, I guess it would basically just be a matter of taking the SDK packaging I removed from SeaMonkey in bug 292268 and add it into the Makefile that packages XULRunner.
At least I hope it would be as easy as that...

Comment 19

[Robert Kaiser]

BTW, the remove Makefile stuff for creating the SDK packages was bascially as follows:

SDK = gecko-sdk-$(TARGET_CPU)-$(TARGET_VENDOR)-$(TARGET_OS)$(PKG_NAME_EXTRAS)$(PKG_SUFFIX)

(for unix:)
PKG_SUFFIX = .tar.bz2
MAKE_SDK = $(CREATE_FINAL_TAR) - gecko-sdk | bzip2 -vf > $(SDK)

(for windows:)
PKG_SUFFIX = .zip
MAKE_SDK = $(ZIP) -r9D $(SDK) gecko-sdk

@rm -rf $(DIST)/gecko-sdk $@
@mkdir $(DIST)/gecko-sdk
@cd $(DIST)/sdk && tar $(TAR_CREATE_FLAGS) - * | (cd ../gecko-sdk; tar -xf -)
cd $(DIST) && $(MAKE_SDK)

Comment 20

[Mike Schroepfer]

Re-assigning to Benjamin since the SDK should be tied with XULRunner releases

Comment 21

[Benjamin Smedberg]

rhelmer is going to manually archive the dist/sdk directory for the 1.8.0.4 xulrunner release, and I'm going to write some tinderbox automation for future releases.

Comment 22

[Alex Vincent [:WeirdAl]]

Indications are this bug is finally fixed:
http://developer.mozilla.org/en/docs/Gecko_SDK

bsmedberg, is there anything left to do for this bug?

Comment 23

[Benjamin Smedberg]

yes, please leave this open for work on automating the SDK publishing. The SDK with 1.8.0.4 was hand-archived, which doesn't scale very well.

Comment 24

[jhp (no longer active)]

Attachment: patch

Patch based on comment #19.

Comment 25

[Benjamin Smedberg]

Comment on attachment 242433 [details] [diff] [review]
patch

Is there any reason not to have SDK-making part of the standard packaging target?

e.g. "libs:: make-sdk"

I think that the package name can/should have the xulrunner name in it:

xulrunner-1.8.1.1.en-US.linux-i686.sdk.tar.gz
which is SDK = $(PKG_BASENAME).sdk.$(PKG_SUFFIX)

With those two changes, r=me

Comment 26

[jhp (no longer active)]

Attachment: patch (checked in)

This is the patch I checked in.  Had to add workaround for Mac, which sets APPNAME to 'xulrunner-pkg', rather than just 'xulrunner'.

Comment 27

[jhp (no longer active)]

Comment on attachment 243390 [details] [diff] [review]
patch (checked in)

Asking for 1.8 branch approval.  Patch is XULRunner only.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 243390 [details] [diff] [review]
patch (checked in)

approved for 1.8 branch, a=dveditz for drivers

Comment 29

[jhp (no longer active)]

Checked in to MOZILLA_1_8_BRANCH.

Comment 30

[Todd A. Fisher]

When is the next build planned for xulrunner that will include the newly packed sdk?