June 2012 - MacRuby-devel - lists.macosforge.org

Re: [MacRuby-devel] MacRuby.h not found
by Jean-Denis MUYS 13 Jun '12

13 Jun '12

This is happening under Lion 10.7.4. Jean-Denis On 12 juin 2012, at 15:55, <macruby-devel-request(a)lists.macosforge.org> Watson <watson1978(a)gmail.com> wrote: > Date: Tue, 12 Jun 2012 20:31:21 +0900 > From: Watson <watson1978(a)gmail.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] MacRuby.h not found > Message-ID: > <CAL5q=W4b1X3zTPbTPM8wbYis9ZB9cCLNvgwE+8ibpTfJ7GXtGQ(a)mail.gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Hi, > > MacRuby does not support Mountain Lion yet. > Please use MacRuby with Lion or Snow Leopard. > > > Thanks > > 2012/6/12 Jean-Denis MUYS <jdmuys(a)kleegroup.com>: >> Hello, >> >> After installing, in order: >> >> - Xcode 4.3.3 (update of 4.3.2) >> - Xcode 4.5DP1 >> - MacRuby 0.12 binary distribution >> >> I create a new MacRuby project (so some MacRuby template is found), but Xcode 4.3.3 fails to compile the main.m file. It chokes on "#import <MacRuby/MacRuby.h>" with the error "MacRuby/MacRuby.h file not found". >> >> I checked that the MacRuby framework appear in my project and is listed in the "Link Binary With Libraries" build phases. >> >> However, it appears in red in both places and file inspector says it's located at "Library/Frameworks/MacRuby.framework", "Relative to Developer Directory". >> >> I'm not sure which is the "Developer Directory" (how can I find out?), but MacRuby.framework sure doesn't appear in my ~/Developer directory. Inspecting the MacRuby installer logs shows that it installed it right in /Library/Frameworks, not in any developer directory. This is confirmed by a search of MacRuby.framework using the mdfind command: MacRuby.framework is only to be found in ?/Library/Frameworks. >> >> xcode-select -print-path reports /Applications/Xcode433.app/Developer, but MacRuby.framework doesn't appear in /Applications/Xcode433.app/Developer/Library/Frameworks. >> >> I tried to replace the MacRuby.framework from the template by the one that is located in /Library/Frameworks. The project now shows it in black, not red, so it's found now. However, I still have the exact same compiler error. >> >> Looking at the Xcode target settings, I found that the Framework Search Paths setting points to the Frameworks directory within Xcode433. >> >> This seems to suggest that the installer installed MacRuby.framework in the wrong location: /Library instead of the currently-selected Xcode directory. >> >> What would be the next step in my case? Is it enough to copy over MacRuby.framework to /Applications/Xcode433.app/Developer/Library/Frameworks? >> >> Thanks, >> >> Jean-Denis >> >> >> PS: to be complete: >> >> Calling "macruby --version" in the terminal reports "MacRuby 0.12 (ruby 1.9.2) [universal-darwin10.0, x86_64]", but if I recall correctly, so did the rather old nightly build I had installed previously. >> >> Calling "which macruby" reports /usr/local/bin/macruby, which is consistent with the MacRuby installer. >> >> >> >> [Logo Kleegroup] >> Klee Group is a great place to work ? Il fait bon travailler ? Klee Group >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >

3 3

mysql gem fails to install
by Jean-Denis MUYS 13 Jun '12

13 Jun '12

Hello again, One of the gem I use is mysql. It used to work. I still have forensic evidence of that in the older place where gems were installed (deep within /Library/Frameworks). Now it doesn't install. Here is the full terminal transcript: Building native extensions. This could take a while... ERROR: Error installing mysql: ERROR: Failed to build gem native extension. /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/bin/macruby extconf.rb checking for mysql_ssl_set()... yes checking for rb_str_set_len()... yes checking for rb_thread_start_timer()... no checking for mysql.h... yes i686-apple-darwin11-llvm-gcc-4.2: conftest.m: No such file or directory i686-apple-darwin11-llvm-gcc-4.2: no input files *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/Library/Frameworks/MacRuby.framework/Versions/0.12/usr/bin/macruby --with-mysql-config --without-mysql-config /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/1.9.2/mkmf.rb:1987:in `mkmf_failed': *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/Library/Frameworks/MacRuby.framework/Versions/0.12/usr/bin/macruby --with-mysql-config --without-mysql-config (SystemExit) from /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/1.9.2/mkmf.rb:2077:in `block' from /Library/Ruby/Gems/MacRuby/0.12/gems/mysql-2.8.1/ext/mysql_api/extconf.rb:75:in `<main>' Gem files will remain installed in /Library/Ruby/Gems/MacRuby/0.12/gems/mysql-2.8.1 for inspection. Results logged to /Library/Ruby/Gems/MacRuby/0.12/gems/mysql-2.8.1/ext/mysql_api/gem_make.out I checked the mkmf.log for more info. Here is its full content: have_func: checking for mysql_ssl_set()... -------------------- yes "/usr/bin/gcc-4.2 -o conftest -I/Library/Frameworks/MacRuby.framework/Versions/0.12/usr/include/ruby-1.9.2/universal-darwin10.0 -I/Library/Frameworks/MacRuby.framework/Versions/0.12/usr/include/ruby-1.9.2/ruby/backward -I/Library/Frameworks/MacRuby.framework/Versions/0.12/usr/include/ruby-1.9.2 -I. -I/opt/local/include/mysql5/mysql -pipe -fPIC -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL -fobjc-gc-only -arch x86_64 -fexceptions -fno-common -pipe -O3 -g -Wall -fobjc-gc-------------------- I tried to execute the call to gcc-4.2 in there. gcc replies "no input files". the mkmf.rb file mentioned is a MacRuby file and the gem installs fine using the regular "gem" command, so I suspect the problem is MacRuby's (especially since I had installed no so long ago), but I am not enough of a rubyist to go further. Any suggestion? Thanks, Jean-Denis [Logo Kleegroup] Klee Group is a great place to work - Il fait bon travailler ? Klee Group

1 0

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 52, Issue 7
by Jean-Denis MUYS 12 Jun '12

12 Jun '12

Arf, OK, thanks. My mistake then. My reduction was incorrect. Indeed when I require 'ruby gems' first in macirb, there is no issue. But the issue remains in my MacRuby app. I get the following error when the app launches: /path/to/rb_main.rb:14: in `<main>': no such file to load -- sequel (LoadError) rb_main.rb read: framework 'Cocoa' require 'ruby gems' require 'sequel' # line 14 Of course I have installed the sequel gem with macgem, and I checked that I can require it in macirb (after rubygems). I suspect this is related to my install issue I described earlier. copying the MacRuby.framework from /Library/Frameworks to within Xcode wasn't good enough after all. (and again, this is all under Lion 10.7.4) So I am back to square one. Any suggestion for installing MacRuby 0.12? Regards, Jean-Denis On 12 juin 2012, at 15:55, <macruby-devel-request(a)lists.macosforge.org<mailto:macruby-devel-request@lists.macosforge.org>> Watson <watson1978(a)gmail.com<mailto:watson1978@gmail.com>> wrote: Message: 6 Date: Tue, 12 Jun 2012 22:52:36 +0900 From: Watson <watson1978(a)gmail.com<mailto:watson1978@gmail.com>> To: "MacRuby development discussions." <macruby-devel(a)lists.macosforge.org<mailto:macruby-devel@lists.macosforge.org>> Subject: Re: [MacRuby-devel] problem using gems with MacRuby 0.12 Message-ID: <CAL5q=W7WuLYJNVmcXrHKyNCQnDvrBAFFYzukpiwj0iAaPME6AA(a)mail.gmail.com<mailto:CAL5q=W7WuLYJNVmcXrHKyNCQnDvrBAFFYzukpiwj0iAaPME6AA@mail.gmail.com>> Content-Type: text/plain; charset=windows-1252 Hi, MacRuby does not load `rubygems' automatically. So, you need 'require "rubygems"' before loading gem which you want. Please refer to http://macruby.macosforge.org/trac/ticket/855 Thanks

1 0

problem using gems with MacRuby 0.12
by Jean-Denis MUYS 12 Jun '12

12 Jun '12

Hi again, It seems there is some issue with MacRuby installing gems, as they don't seem to be made available to macirb: sudo macgem install --remote progressbar succeeds. macgem list --local mentions progressbar just fine macirb irb(main):001:0> require 'progressbar' LoadError: no such file to load -- progressbar The same try using the regular gem and irb works fine. I really don't know what to do here. Any help welcome. Jean-Denis [Logo Kleegroup] Klee Group is a great place to work – Il fait bon travailler à Klee Group

2 1

MacRuby.h not found
by Jean-Denis MUYS 12 Jun '12

12 Jun '12

Hello, After installing, in order: - Xcode 4.3.3 (update of 4.3.2) - Xcode 4.5DP1 - MacRuby 0.12 binary distribution I create a new MacRuby project (so some MacRuby template is found), but Xcode 4.3.3 fails to compile the main.m file. It chokes on "#import <MacRuby/MacRuby.h>" with the error "MacRuby/MacRuby.h file not found". I checked that the MacRuby framework appear in my project and is listed in the "Link Binary With Libraries" build phases. However, it appears in red in both places and file inspector says it's located at "Library/Frameworks/MacRuby.framework", "Relative to Developer Directory". I'm not sure which is the "Developer Directory" (how can I find out?), but MacRuby.framework sure doesn't appear in my ~/Developer directory. Inspecting the MacRuby installer logs shows that it installed it right in /Library/Frameworks, not in any developer directory. This is confirmed by a search of MacRuby.framework using the mdfind command: MacRuby.framework is only to be found in /Library/Frameworks. xcode-select -print-path reports /Applications/Xcode433.app/Developer, but MacRuby.framework doesn't appear in /Applications/Xcode433.app/Developer/Library/Frameworks. I tried to replace the MacRuby.framework from the template by the one that is located in /Library/Frameworks. The project now shows it in black, not red, so it's found now. However, I still have the exact same compiler error. Looking at the Xcode target settings, I found that the Framework Search Paths setting points to the Frameworks directory within Xcode433. This seems to suggest that the installer installed MacRuby.framework in the wrong location: /Library instead of the currently-selected Xcode directory. What would be the next step in my case? Is it enough to copy over MacRuby.framework to /Applications/Xcode433.app/Developer/Library/Frameworks? Thanks, Jean-Denis PS: to be complete: Calling "macruby --version" in the terminal reports "MacRuby 0.12 (ruby 1.9.2) [universal-darwin10.0, x86_64]", but if I recall correctly, so did the rather old nightly build I had installed previously. Calling "which macruby" reports /usr/local/bin/macruby, which is consistent with the MacRuby installer. [Logo Kleegroup] Klee Group is a great place to work – Il fait bon travailler à Klee Group

2 2

MacRuby 0.12 release note
by Watson 11 Jun '12

11 Jun '12

MacRuby 0.12 is now available. What's new in this release (since 0.10): - Improve stability and compatibility by total 1168 commits - Changed RUBY_AUTHOR to "The MacRuby Team" - Add support for XCode 4.3 - Drop support for XCode 4.2 and earlier - Upgrade to RubyGems 1.8.20 - Upgrade to Rake 0.9.2.2 - Add the --codesign option to macruby_deploy - Gems are now installed to /Library/Ruby/Gems/MacRuby - Remove obsoleted constants RUBY_FRAMEWORK and RUBY_FRAMEWORK_VERSION from RbConfig - macrubyc/macruby_deploy now uses proper exit codes for --help and --version options - The instruby.rb script has been replaced with a set of rake tasks - Upgrade JSON to 1.6.5 - Cocoa objects now use #description for their #inspect output - Added Pointer#value shortcut to Pointer#[0] - Update to new ruby license - Improve some methods of String/Array performance - Add Range#relative_to(max) - Add Pointer#to_object - Import JSON 1.5.1 - Upgrade RDoc to 3.5.3 Binary packages will be available from: https://github.com/downloads/MacRuby/MacRuby/MacRuby%200.12.zip We moved MacRuby web site, issue tracker and documents to GitHub: - http://macruby.org/ - https://github.com/MacRuby/MacRuby/issues - https://github.com/MacRuby/MacRuby/wiki Old site is available yet (http://macruby.macosforge.org/) If you are interested in iOS development on MacRuby, we could already get it as RubyMotion (http://www.rubymotion.com/) :) Cheers

6 6

Re: [MacRuby-devel] Appstore rules on symlinks Macruby
by Rob Ista 11 Jun '12

11 Jun '12

Thanks Mark (and the full team for finalizing 0.12 as well :)), I've seen in the NB 0.13 that there is a framework that should pass the review (I assume that Apple is not complaining against "0.13" in stead of "A"). I already had a review pending but i'l give it a try the next time. One question though, the existence of the dylib and the symlinks in /lib suggest that there are references to them? Is that true or is at the end of the day a Macruby binary sufficient? I just opened a ticket for a possible bug of popen3 in 1.9.2 but I'll open another ticket for the code signing "materializing" thing. keep up the good work, Rob On 9 Jun 2012, at 16:00 , macruby-devel-request(a)lists.macosforge.org wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel(a)lists.macosforge.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > or, via email, send a message with subject or body 'help' to > macruby-devel-request(a)lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-owner(a)lists.macosforge.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MacRuby-devel digest..." > > > Today's Topics: > > 1. Re: Appstore rules on symlinks Macruby (Mark Rada) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Jun 2012 21:59:28 -0400 > From: Mark Rada <mrada(a)marketcircle.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby > Message-ID: <34A5CD21-9CE9-40CC-8AE6-5A2DE4303667(a)marketcircle.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Rob, > > Someone else opened a ticket on Github that describes the same problem that you were having (https://github.com/MacRuby/MacRuby/issues/101) > > I've taken a stab at fixing the issue and the nightly build of MacRuby seems to have gotten past this problem. Granted, I did the minimum amount work to get things working. I have not gone through to make sure MacRuby.framework is "by the books", and the symlink materialization problem is something that still needs to be dealt with, but for the time being a stock MacRuby installation should now be passing app store automatic validation. > > Opening tickets on github for some of the things you've outlined here would help out. > > Thanks, > Mark > > > On 2012-06-04, at 9:08 AM, rob ista wrote: > >> Hi, obviously filing a bug has a broken link now so ... >> >> - Apple indeed wants the Version to be A (or B) so macruby_deploy has to be changed. All exactly like Apple wants it to. >> - I personally didn't succeed in doing so, so i decided to leave that to the pro's and have built a "by-the book ready-to-go" MacRuby-framework including the Headers and all. Significant detail is that I removed all the .dylibs (I didn't have seen a malfunction for that thus far) including their symlinks and only have a MacRuby binary (a copy of the dylib) where it shoud be including a symlink on top-level because >> - codesigning "materializes" all symlinks into real binaries. E.g. you'll end up with 3 fullsize binary dylibs in the /lib folder with an exploded app-size as a result >> - that's why you shouldn''t codesign a xyz.framework itself but the real Version(s) ("A", "B" etc.) because it would "materialize" all symlinks it can find including the one pointing to the main binary >> - codesigning .rb files is not necessary anymore, only the .rbo's and the .bundle's >> - so, i just deploy an app, remove the macruby framework which was built by macruby deploy, replace it with my "by-the-book ready-to-go" one, run my post-compile script which "hacks" the binaries again with the Version (it should work with Current as well i guess), remove the Header-stuff and codesigns everything in the right order (first the rbo's etc., then the framework Version, then the app) >> - and .... no errors or even warnings when uploading to the store. The app even works and is accepted :) >> >> Personally i think it's more convenient to have that "ready-to-go"' framework in the nightly builds and copy it during deployment. Hacking a framework together is a bit fuzzy and lookes like everything is still in beta. Well, even if it is, i think we should avoid it :). May be it's then even possible to avoid having to hack the binaries as well and only codesign the details before uploading. >> >> cheers, Rob >> >> >> On 10 May, 2012,at 04:00 PM, macruby-devel-request(a)lists.macosforge.org wrote: >> >>> Send MacRuby-devel mailing list submissions to >>> macruby-devel(a)lists.macosforge.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> or, via email, send a message with subject or body 'help' to >>> macruby-devel-request(a)lists.macosforge.org >>> >>> You can reach the person managing the list at >>> macruby-devel-owner(a)lists.macosforgeorg >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of MacRuby-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Appstore rules on symlinks Macruby framework changed ? >>> (Rob Ista) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 09 May 2012 16:44:01 +0200 >>> From: Rob Ista <rob.ista(a)me.com> >>> To: macruby-devel(a)lists.macosforge.org >>> Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby >>> framework changed ? >>> Message-ID: <B1B2E2DD-95D9-44D3-81F1-2BFF161EAD7F(a)me.com> >>> Content-Type: text/plain; charset=windows-1252 >>> >>> Yes, i have seen that .. i will do some tests to see if i can get a working app with a symlink although a manual change did not succeed thus far .. either it cannot find macgems (if i hack the binary with "A") or it just crashes because it can not find "Current" through the simlink any more >>> >>> and yes, it seems that apple is really stretching their rules to the limits .. i sensed some disturbance in the python community as well with similar issues the last few days ? the response from the review team was : >>> - - - - - >>> Dear developer, >>> >>> We have discovered one or more issues with your recent delivery for "SubtitleReSync". To process your delivery, the following issues must be corrected: >>> >>> Malformed Framework - The framework bundle MacRuby (SubtitleReSync.app/Contents/Frameworks/MacRuby.framework) 'Versions' directory must contain a symbolic link 'Current' resolving to a specific version directory. Refer to the Anatomy of Framework Bundles for more information. >>> - - - - - >>> >>> The funny thing is that i have another framework but didn't bother to create a "cute" one so i just dumped the .dylib into Frameworks. That seems to be allowed and ok :) >>> >>> I will file a bug report as well >>> >>> cheers, Rob >>> >>>> >>>> macruby_deploy fiddles with the version symlinks on purpose. We changed it in the past for app store guidelines at some point; you should be able to see it in the history of macruby_deploy. >>>> >>>> It would be fastest to just revert that change and see if that fixes things. Though if Apple really wants the version to be A then we will need to do a bit more work. >>>> >>>> macruby_deploy is fairly straightforward, so it is easy to go through and find what needs to be changed. >>>> >>>> >>>> Sent from my iDevice >>>> >>>> On 2012-05-07, at 9:38, Joshua Ballanco <jballanc(a)gmail.com> wrote: >>>> >>>>> Hi Rob, >>>>> >>>>> I haven't had time to look into it, but hopefully Apple is not looking to restrict versions within framework bundles to "A", "B", "C", etc. As for "Current" not being a symlink, that does seem like a bug. Would you mind filing it as such so that we don't loose track of it? >>>>> >>>>> - Josh >>>>> On Saturday, May 5, 2012 at 8:27 PM, Rob Ista wrote: >>>>> >>>>>> Hi all, >>>>>> it seems that the Appstore validation has sharpened its control (again) ? submitting an app now is rejected because the Macruby framework does not comply to the official Anatomy of Framework Bundles ? There should be a symbolic "Current" resolving to "A" ... in the Macruby Framework this is now a fixed "Current" .. does anyone have seen this before and is there a workaround for the time being ? >>>>>> >>>>>> Secondly, the code signing of the bundle contents is still a bit shaky although it seems to work on Lion .. on SL the .rb files create an "argument list too long" message (see below) .. commenting out the .rb files in macruby_deploy for codesigning makes the deploy come to a proper end but of course now the .rb are not signed. Daniel has done some great work on this already but are there any other ideas? >>>>>> >>>>>> rgrds, Rob >>>>>> >>>>>> /Users/robista/Library/Developer/Xcode/DerivedData/SubtitleReSyncBasic-ayrbtqtujxpvspgaanykiwlaojxy/ArchiveIntermediates/Deployment/BuildProductsPath/Release/SubtitleReSyncBasic.app/Contents/Frameworks/MacRuby.framework/Versions/Current/usr/lib/ruby/1.9.2/abbrev.rb: Argument list too long >>>>>> _______________________________________________ >>>>>> >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel(a)lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> >>> End of MacRuby-devel Digest, Vol 51, Issue 14 >>> ********************************************* >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > >

1 0

Re: [MacRuby-devel] Appstore rules on symlinks Macruby
by rob ista 09 Jun '12

09 Jun '12

Hi, obviously filing a bug has a broken link now so ... - Apple indeed wants the Version to be A (or B) so macruby_deploy has to be changed. All exactly like Apple wants it to. - I personally didn't succeed in doing so, so i decided to leave that to the pro's and have built a "by-the book ready-to-go" MacRuby-framework including the Headers and all. Significant detail is that I removed all the .dylibs (I didn't have seen a malfunction for that thus far) including their symlinks and only have a MacRuby binary (a copy of the dylib) where it shoud be including a symlink on top-level because - codesigning "materializes" all symlinks into real binaries. E.g. you'll end up with 3 fullsize binary dylibs in the /lib folder with an exploded app-size as a result - that's why you shouldn''t codesign a xyz.framework itself but the real Version(s) ("A", "B" etc.) because it would "materialize" all symlinks it can find including the one pointing to the main binary - codesigning .rb files is not necessary anymore, only the .rbo's and the bundle's - so, i just deploy an app, remove the macruby framework which was built by macruby deploy, replace it with my "by-the-book ready-to-go" one, run my post-compile script which "hacks" the binaries again with the Version (it should work with Current as well i guess), remove the Header-stuff and codesigns everything in the right order (first the .rbo's etc., then the framework Version, then the app) - and .... no errors or even warnings when uploading to the store. The app even works and is accepted :) Personally i think it's more convenient to have that "ready-to-go"' framework in the nightly builds and copy it during deployment. Hacking a framework together is a bit fuzzy and lookes like everything is still in beta. Well, even if it is, i think we should avoid it :). May be it's then even possible to avoid having to hack the binaries as well and only codesign the details before uploading. cheers, Rob On 10 May, 2012,at 04:00 PM, macruby-devel-request(a)lists.macosforge.org wrote: Send MacRuby-devel mailing list submissions to macruby-devel(a)lists.macosforge.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel or, via email, send a message with subject or body 'help' to macruby-devel-request(a)lists.macosforge.org You can reach the person managing the list at macruby-devel-owner(a)lists.macosforge.org When replying, please edit your Subject line so it is more specific than "Re: Contents of MacRuby-devel digest..." Today's Topics: 1. Re: Appstore rules on symlinks Macruby framework changed ? (Rob Ista) ---------------------------------------------------------------------- Message: 1 Date: Wed, 09 May 2012 16:44:01 +0200 From: Rob Ista <rob.ista(a)me.com> To: macruby-devel(a)lists.macosforge.org Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby framework changed ? Message-ID: <B1B2E2DD-95D9-44D3-81F1-2BFF161EAD7F(a)me.com> Content-Type: text/plain; charset=windows-1252 Yes, i have seen that .. i will do some tests to see if i can get a working app with a symlink although a manual change did not succeed thus far .. either it cannot find macgems (if i hack the binary with "A") or it just crashes because it can not find "Current" through the simlink any more and yes, it seems that apple is really stretching their rules to the limits .. i sensed some disturbance in the python community as well with similar issues the last few days ? the response from the review team was : - - - - - Dear developer, We have discovered one or more issues with your recent delivery for "SubtitleReSync". To process your delivery, the following issues must be corrected: Malformed Framework - The framework bundle MacRuby (SubtitleReSync.app/Contents/Frameworks/MacRuby.framework) 'Versions' directory must contain a symbolic link 'Current' resolving to a specific version directory. Refer to the Anatomy of Framework Bundles for more information. - - - - - The funny thing is that i have another framework but didn't bother to create a "cute" one so i just dumped the .dylib into Frameworks. That seems to be allowed and ok :) I will file a bug report as well cheers, Rob > > macruby_deploy fiddles with the version symlinks on purpose. We changed it in the past for app store guidelines at some point; you should be able to see it in the history of macruby_deploy. > > It would be fastest to just revert that change and see if that fixes things. Though if Apple really wants the version to be A then we will need to do a bit more work. > > macruby_deploy is fairly straightforward, so it is easy to go through and find what needs to be changed. > > > Sent from my iDevice > > On 2012-05-07, at 9:38, Joshua Ballanco <jballanc(a)gmail.com> wrote: > >> Hi Rob, >> >> I haven't had time to look into it, but hopefully Apple is not looking to restrict versions within framework bundles to "A", "B", "C", etc. As for "Current" not being a symlink, that does seem like a bug. Would you mind filing it as such so that we don't loose track of it? >> >> - Josh >> On Saturday, May 5, 2012 at 8:27 PM, Rob Ista wrote: >> >>> Hi all, >>> it seems that the Appstore validation has sharpened its control (again) ? submitting an app now is rejected because the Macruby framework does not comply to the official Anatomy of Framework Bundles ? There should be a symbolic "Current" resolving to "A" ... in the Macruby Framework this is now a fixed "Current" .. does anyone have seen this before and is there a workaround for the time being ? >>> >>> Secondly, the code signing of the bundle contents is still a bit shaky although it seems to work on Lion .. on SL the .rb files create an "argument list too long" message (see below) .. commenting out the .rb files in macruby_deploy for codesigning makes the deploy come to a proper end but of course now the .rb are not signed. Daniel has done some great work on this already but are there any other ideas? >>> >>> rgrds, Rob >>> >>> /Users/robista/Library/Developer/Xcode/DerivedData/SubtitleReSyncBasic-ayrbtqtujxpvspgaanykiwlaojxy/ArchiveIntermediates/Deployment/BuildProductsPath/Release/SubtitleReSyncBasic.app/Contents/Frameworks/MacRuby.framework/Versions/Current/usr/lib/ruby/1.9.2/abbrev.rb: Argument list too long >>> _______________________________________________ >>> ------------------------------ _______________________________________________ MacRuby-devel mailing list MacRuby-devel(a)lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel End of MacRuby-devel Digest, Vol 51, Issue 14 *********************************************

2 1