Allow embedding of arbitrary versions of MacRuby

[self@…]

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.

[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

[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.

[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

[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.

[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/

[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.

[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.

[self@…]

Replying to 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.

[self@…]

Replying to 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?