[MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- However the new embedding approach for MacRuby should work it should not be dependent upon the version of MacRuby that is installed on the system (ideally it should not even be dependent upon there *being* a version of MacRuby installed). The primary use case is anticipating needing 0.4, 0.5, or 1.0 installed for apps that I am running that depend upon MacRuby (e.g. LimeChat when it moves across) and wanting to deploy other versions (e.g. trunk) in my own application. I'm also not keen on the removal of the build_as_embeddable option and a new dependency upon Xcode. I would rather this problem were solved by keeping the build_as_embeddable rask task and having that task patch the dylibs and and embed them into MR itself (rather than into my application). The way things are going MacRuby is forcing its dependencies into my project. I want to treat it just like any other framework I link to. -- Ticket URL: <http://www.macruby.org/trac/ticket/174> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): Re-reading I wish I hadn't written "The way things are going" it sounds too ominous, it was just the first phrase that came into my head. The basis of what I am trying to articulate is a clean separation of concerns between MacRuby and my application. Regards, Matt -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:1> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by lsansonetti@…): JFYI, {{{build_as_embeddable}}} was removed because it's really not necessary anymore. You can still embed a given version of MacRuby in your app by doing: {{{ $ rake $ DESTDIR=/tmp/foo rake install $ mkdir -p /path/to/MyApp.app/Contents/Frameworks $ cp -r /tmp/foo/Library/Frameworks/MacRuby.framework /path/to/MyApp.app/Contents/Frameworks }}} Then use the Xcode target, or: {{{ $ macruby -r hotcocoa/application_builder -e "HotCocoa::ApplicationBuilder.deploy(ARGV[0])" /path/to/MyApp.app }}} Now, this is quite painful to do. We should introduce a way to deploy a specific version of the framework. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:2> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): I've been having a lot of problems with this. I can't make the Xcode target work at all and, because of a confusion, I managed to release a version update without the bridge support metadata and am getting crash reports. I think this process is brittle and introduces unnecessary dependencies into my project not to mention adding several seconds to each build cycle (whether needed or not and they do add up). I would like, instead, to see the MacRuby build process (perhaps governed by some kind of flag) embed the bridge support metadata into the MacRuby.framework bundle itself and look for them there first. This would eliminate any dependency in my application project and allow me to treat MacRuby.framework as I would any other framework (which is a very good thing). It would also considerably reduce the change that I will ever again release a binary without the patched metadata. I took a look at bs.c but, although the relevant area is obvious enough to spot, I would not be confident to make this change myself. The "Ruby C" coding style is not for the faint hearted. Matt -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:3> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by lsansonetti@…): I have been using the Xcode target for quite some time here, what kind of problems did you really experience? The idea behind the target is to not build it during development, but only to release a deployment version for release. If the target does not satisfy you, you can still use the command line exactly as before (see my reply above). There are really more than one way to do it (even if the Xcode target is IMHO the easiest way). I don't think that modifying the BridgeSupport parser to look for BridgeSupport files inside the framework is a good idea, because it violates the BridgeSupport load path that we discussed a year ago with the PyObjC guys. This dylib problem is also very temporary as I said, it is the plan to address this in an future software update for Leopard. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:4> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): For me the Xcode target has never embedded the metadata. By default it seems to add itself to the list of targets, there it does nothing I can observe. If I try and drag it under the Application target itself the script generates an error because it won't go after the compile sources build phase.
I don't think that modifying the BridgeSupport parser to look for BridgeSupport files inside the framework is a good idea, because it violates the BridgeSupport load path that we discussed a year ago with the PyObjC guys.
And then in the very next sentence you say the problem is temporary. So, given that, why not adopt this approach temporarily? It may not be what you discussed with the PyObjC folks but it's the best solution for your users. How are PyObjC even going to know if you add MR itself at the front of the load path? Why do they care? m/ -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:5> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): It also seems that the change from using BUILD_AS_EMBEDDABLE has broken something. http://pastie.org/private/7kgbttwif2q1sad1o6uva I wrote my own script run phase to embed the metadata (using your original shell script which I know works because that's what was using to generate Elysium 0.8.2 which did work for people) and Andy has confirmed it's there. I've now released two versions of Elysium which have been broken: 0.8.3 didn't include the metadata, and 0.8.4 MacRuby seems not to be able to find itself. m. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:6> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by lsansonetti@…): {{{ For me the Xcode target has never embedded the metadata. By default it seems to add itself to the list of targets, there it does nothing I can observe. If I try and drag it under the Application target itself the script generates an error because it won't go after the compile sources build phase. }}} Once you add the Xcode target you need to manually build it, like any other Xcode targets. It will not build by default (which is the idea). {{{ And then in the very next sentence you say the problem is temporary. So, given that, why not adopt this approach temporarily? It may not be what you discussed with the PyObjC folks but it's the best solution for your users. How are PyObjC even going to know if you add MR itself at the front of the load path? Why do they care? }}} I am not planning to do any more changes since the current solution works. It's worthless to spend more time since this problem is temporary. {{{ It also seems that the change from using BUILD_AS_EMBEDDABLE has broken something. http://pastie.org/private/7kgbttwif2q1sad1o6uva I wrote my own script run phase to embed the metadata (using your original shell script which I know works because that's what was using to generate Elysium 0.8.2 which did work for people) and Andy has confirmed it's there. I've now released two versions of Elysium which have been broken: 0.8.3 didn't include the metadata, and 0.8.4 MacRuby seems not to be able to find itself. }}} Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle? The current system works fine for me, I tested it on several apps and used these apps on pure Leopard systems. If it does not work for you please report me more information (if possible with a sample project or a version of Elysium). This should really be discussed on the mailing list. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:7> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): Replying to [comment:7 lsansonetti@…]:
{{{ For me the Xcode target has never embedded the metadata. By default it seems to add itself to the list of targets, there it does nothing I can observe. If I try and drag it under the Application target itself the script generates an error because it won't go after the compile sources build phase. }}}
Once you add the Xcode target you need to manually build it, like any other Xcode targets. It will not build by default (which is the idea).
This whole process seems to me to be systematically prone to error.
I am not planning to do any more changes since the current solution works. It's worthless to spend more time since this problem is temporary.
Very well. It is your decision as the owner of the project. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:8> MacRuby <http://macruby.org/>
#174: Allow embedding of arbitrary versions of MacRuby --------------------------------+------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by self@…): Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
Okay for some reason it is now linking against MacRuby in /Library. Why? It's never done that before.
This should really be discussed on the mailing list.
Uh. You mean I shouldn't report problems here? -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:9> MacRuby <http://macruby.org/>
Guys? This is a very suboptimal, to say nothing of weird, way to communicate, I hope you both realize. :) - Jordan On Dec 8, 2008, at 2:51 AM, MacRuby wrote:
#174: Allow embedding of arbitrary versions of MacRuby -------------------------------- +------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: -------------------------------- +-------------------------------------------
Comment(by self@…):
Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
Okay for some reason it is now linking against MacRuby in /Library. Why? It's never done that before.
This should really be discussed on the mailing list.
Uh. You mean I shouldn't report problems here?
-- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:9> MacRuby <http://macruby.org/>
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
About this. More than anything, I'd like to keep discussions on the ML, because I cannot express enough the hatred I feel for the format of Trac's emails :-) Eloy On 8 dec 2008, at 22:35, Jordan K. Hubbard wrote:
Guys?
This is a very suboptimal, to say nothing of weird, way to communicate, I hope you both realize. :)
- Jordan
On Dec 8, 2008, at 2:51 AM, MacRuby wrote:
#174: Allow embedding of arbitrary versions of MacRuby -------------------------------- +------------------------------------------- Reporter: self@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: -------------------------------- +-------------------------------------------
Comment(by self@…):
Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
Okay for some reason it is now linking against MacRuby in /Library. Why? It's never done that before.
This should really be discussed on the mailing list.
Uh. You mean I shouldn't report problems here?
-- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:9> MacRuby <http://macruby.org/>
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Mon, Dec 8, 2008 at 10:51 AM, MacRuby <ruby-noreply@macosforge.org> wrote:
Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
As far as I understand it there are two issues: 1) broken BS metadata 2) where does MacRuby get looked for As of a couple of (MacRuby) builds ago I had no problem with either. I had a run script phase in my existing target (using Laurents script) to embed the right metadata. I note that Laurent created an Xcode target for MacRuby but it doesn't fit into my build workflow and, therefore, I don't want to use it. I would like the BUILD_AS_EMBEDDABLE option back and to be able to manage MacRuby.framework myself as I would any other framework. Regards, Matt -- Matt Mower :: http://matt.blogs.it/
Hiya, As someone experiencing this discussion from the 3rd person perspective, I'd like to chime in. The current issue seems to be that there are some problems with the current MR, which will get properly fixed by a future software update. Until then there apparently is the need to work around this in different ways. Laurent added his, but it broke Matts existing one. So my question to Laurent is, since it's _all_ suboptimal atm, would it be possible to re-enable the BUILD_AS_EMBEDDABLE option so everyone can go on without wasting time on a tmp workaround? Cheers, Eloy "always in for a discussion" Duran ;-) On 9 dec 2008, at 16:18, Matt Mower wrote:
On Mon, Dec 8, 2008 at 10:51 AM, MacRuby <ruby- noreply@macosforge.org> wrote:
Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
As far as I understand it there are two issues:
1) broken BS metadata 2) where does MacRuby get looked for
As of a couple of (MacRuby) builds ago I had no problem with either. I had a run script phase in my existing target (using Laurents script) to embed the right metadata.
I note that Laurent created an Xcode target for MacRuby but it doesn't fit into my build workflow and, therefore, I don't want to use it.
I would like the BUILD_AS_EMBEDDABLE option back and to be able to manage MacRuby.framework myself as I would any other framework.
Regards,
Matt
-- Matt Mower :: http://matt.blogs.it/ _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Dec 9, 2008, at 7:18 AM, Matt Mower wrote:
On Mon, Dec 8, 2008 at 10:51 AM, MacRuby <ruby- noreply@macosforge.org> wrote:
Replying to [comment:7 lsansonetti@…]:
Did you verify with {{{otool(1)}}} that your binary links against the version of MacRuby inside the bundle?
As far as I understand it there are two issues:
1) broken BS metadata 2) where does MacRuby get looked for
As of a couple of (MacRuby) builds ago I had no problem with either. I had a run script phase in my existing target (using Laurents script) to embed the right metadata.
I note that Laurent created an Xcode target for MacRuby but it doesn't fit into my build workflow and, therefore, I don't want to use it.
Okay.
I would like the BUILD_AS_EMBEDDABLE option back and to be able to manage MacRuby.framework myself as I would any other framework.
If you want to manage this by yourself check out the following snippet that I pasted in the trac report 6 days ago. Build the version of MacRuby of your choice (can be any version): $ rake $ DESTDIR=/tmp/foo rake install Then embed it in your app: $ mkdir -p /path/to/MyApp.app/Contents/Frameworks $ cp -r /tmp/foo/Library/Frameworks/MacRuby.framework /path/to/ MyApp.app/Contents/Frameworks $ macruby -r hotcocoa/application_builder -e "HotCocoa::ApplicationBuilder.deploy(ARGV[0])" /path/to/MyApp.app This will basically do 3 things: 1) copy the version of MacRuby.framework that you built inside your app 2) change the install name of your app so that it links against the version of MacRuby inside it 3) copy the missing bridgesupport dylib files BUILD_AS_EMBEDDABLE did nothing more than building the framework as relocatable, which is _exactly_ what the hotcocoa/application_builder does. So there is really no need for it. Please look at the source code if you don't believe me. If you find a bug please tell me. If really you cannot live with BUILD_AS_EMBEDDABLE (for a reason I ignore) you're still free to add it in your personal repository copy. Laurent
On Tue, Dec 9, 2008 at 7:32 PM, Laurent Sansonetti <lsansonetti@apple.com> wrote:
If really you cannot live with BUILD_AS_EMBEDDABLE (for a reason I ignore) you're still free to add it in your personal repository copy.
Very well. I have now spent the time to figure out how to patch the Rakefile, instruby.rb, and bs.c to a) build the framework relocatable b) embed the patched bridge support metadata into macruby.framework itself c) load patched bridge support metadata from inside macruby.framework instead of the app bundle So far it seem to works and the resulting version of MacRuby.framework is suitable for embedding and can be treated just like any other framework. I've put my patches on GitHub: http://github.com/mmower/embeddable-macruby/tree/master Matt -- Matt Mower :: http://matt.blogs.it/
participants (5)
-
Eloy Duran
-
Jordan K. Hubbard
-
Laurent Sansonetti
-
MacRuby
-
Matt Mower