931841 - XULRunner on OS X doesn't include xulrunner-stub

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: XULRunner, defect)

Description

[Peter Van der Beken [:peterv]]

Bug 756786 renamed the program built by xulrunner/app/Makefile.in to 'xulrunner' from 'xulrunner-bin', but we already build the stub on OS X as just 'xulrunner' (configure.in sets XULRUNNER_STUB_NAME differently for OS X). The end result is that we don't ship the stub at all on OS X, and all instructions on the web are now probably wrong, because they refer to the stub as 'xulrunner'.

Comment 1

[Peter Van der Beken [:peterv]]

I guess reverting bug 756786 is not a good idea (even if only on OS X)? So should we rename the stub to xulrunner-stub on OS X too (and hope docs get updated)?

Comment 2

[Mike Hommey [:glandium]]

bug 812918 removed xulrunner-stub from dist/bin ; but it should still be in the framework/sdk. dev-doc-needed, I guess.

Comment 3

[Peter Van der Beken [:peterv]]

So you're saying the 'xulrunner' binary installed from toolkit/app should be overwritten by the identically named 'xulrunner' binary from toolkit/stub?

Comment 4

[Mike Hommey [:glandium]]

No, I'm saying it's *not* overwritten. xulrunner from xulrunner/app is in dist/bin (meaning it's in the xulrunner package) and xulrunner from xulrunner/stub is in Framework/something. I'm not sure where that ends up ; i presume the sdk.

Comment 5

[Peter Van der Beken [:peterv]]

We explicitly rsync dist/bin into the framework directory in toolkit/app, so I'm not sure how you think it's not ending up in the framework: http://hg.mozilla.org/mozilla-central/annotate/c5e4bb7db0b9/xulrunner/app/Makefile.in#l138 As a matter of fact, building with --with-xulrunner-stub-name=xulrunner-stub results in both xulrunner (from toolkit/app) and xulrunner-stub (from toolkit/stub) in the framework.
Given all that, should xulrunner/app/Makefile.in then not rsync xulrunner explicitly?

Comment 6

[Mike Hommey [:glandium]]

(In reply to Peter Van der Beken [:peterv] from comment #5)
> We explicitly rsync dist/bin into the framework directory in toolkit/app, so
> I'm not sure how you think it's not ending up in the framework:
> http://hg.mozilla.org/mozilla-central/annotate/c5e4bb7db0b9/xulrunner/app/
> Makefile.in#l138 As a matter of fact, building with
> --with-xulrunner-stub-name=xulrunner-stub results in both xulrunner (from
> toolkit/app) and xulrunner-stub (from toolkit/stub) in the framework.

Oh my... what a pile of cr*p.

> Given all that, should xulrunner/app/Makefile.in then not rsync xulrunner
> explicitly?

That would seem like the right thing to do. OTOH, I'm not entirely sure what the expectations are about the framework from its consumers. I'm only half surprised it took so long to notice it's busted.

Comment 7

[Alex Vincent [:WeirdAl]]

XR on Mac has been busted for a while:  see bug 923979, which may be unrelated.  A patch for that bug will land soon.

Comment 8

[Alex Vincent [:WeirdAl]]

Also, for the record, I'm working on replacing install-app capabilities with a Python script that's supposed to actually work (bug 747597) and including a make check test (bug 448069).

Comment 9

[Benjamin Smedberg]

XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context.

I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.