Sounds good for me. On May 5, 2011, at 4:25 PM, Eloy Duran wrote:
> Hmm, yes this is a problem. Maybe we should add separate options for > compiling stdlib and gems and start keeping a list of libs known to not work > well with AOT compilation which can then be excluded? I don't like adding > another option so we could also compile everything with --compile, but this > might introduce problems for users with libs of which we don't yet know if > they work well. > > I personally prefer the latter, because it keeps the interface of ruby_deploy > simple and forcing people to run into potential bugs is the only good way to > find these problem libs. However, from a user friendly pov opt-in might be > better, but it's much less likely that people will report about broken libs > in that case. > > On 5 mei 2011, at 15:49, Nick Ludlam wrote: > >> I think Laurent and I were discussing some issues with the AOT compiling of >> certain stdlib files causing problems. My specific case was from the RSS >> module. >> >> https://www.macruby.org/trac/ticket/1020 >> >> On 5 May 2011, at 14:39, Eloy Duran wrote: >> >>> Aha indeed! Yes we should definitely compile them imo. But I’m not >>> sure if there’s a good reason for excluding stdlib and gems from >>> compilation. The last time I tried there was no problem with compiling >>> it all. Can you change this in source/bin/ruby_deploy and see if your >>> app works good afterwards? If so I’ll apply that, right now I’m going >>> to start on a test suite for the tool as it is. >>> >>> On Thu, May 5, 2011 at 2:58 PM, Petr Kaleta <petr.kal...@me.com> wrote: >>>> Yes, you said, that it compile all files from Resources directory, but >>>> gems are embeded in Framework directory. So thats why, they are not >>>> compiled. Can be STDLIB compiled as well? >>>> >>>> - Petr >>>> >>>> On May 5, 2011, at 2:34 PM, Eloy Duran wrote: >>>> >>>>> No, that's not right. The embed code is run before the compile code >>>>> and the compile code uses the following to select all ruby files in >>>>> the Resources directory of the app bundle: >>>>> >>>>> def compile_files >>>>> Dir.glob(File.join(app_resources, '**', '*.rb')) >>>>> end >>>>> >>>>> It would be great if you can upload a sample that shows this. >>>>> >>>>> On Thu, May 5, 2011 at 2:11 PM, Petr Kaleta <petr.kal...@me.com> wrote: >>>>>> Now I am looking in the application package and embeded gems are not >>>>>> compiled. And as you can see here http://cl.ly/240t0v3q2O221X3U113u some >>>>>> ruby files compiled are, but there are source files as well. Embeded >>>>>> STDlib is not compiled at all http://cl.ly/2d2D2R2L451m2C2x472J >>>>>> >>>>>> Is this right? >>>>>> >>>>>> On May 5, 2011, at 1:27 PM, Petr Kaleta wrote: >>>>>> >>>>>>> Thanks for reply, that works. So after deploying, my whole application >>>>>>> has about 45MB (zipped 12MB). My only question is, can I somehow >>>>>>> speedup application start? Now it takes about 10 seconds (loading gems >>>>>>> & project files). >>>>>>> >>>>>>> - Petr >>>>>>> >>>>>>> On May 5, 2011, at 12:13 PM, Eloy Duran wrote: >>>>>>> >>>>>>>> No it's not your fault, it seems the code assumes a ENV variable >>>>>>>> that's set by Xcode. This is the offending code: >>>>>>>> >>>>>>>> compile_options = { bundle: true, output: obj, files: [source] } >>>>>>>> # Use Xcode ARCHS env var to determine which archs to compile for >>>>>>>> compile_options[:archs] = ENV['ARCHS'].strip.split if ENV['ARCHS'] >>>>>>>> # Check that the ARCHS env var contains valid values >>>>>>>> supported_archs = RbConfig::CONFIG['ARCH_FLAG'].gsub('-arch', >>>>>>>> '').strip.split >>>>>>>> compile_options[:archs].delete_if do |arch| >>>>>>>> unless supported_archs.include?(arch) >>>>>>>> puts "Can't build for arch #{arch} because it is not supported" >>>>>>>> true >>>>>>>> end >>>>>>>> end >>>>>>>> >>>>>>>> I think that if the ENV['ARCHS'] variable isn't set we should check >>>>>>>> the app binary for the archs it's been built for. I'll create a path >>>>>>>> in a bit. >>>>>>>> >>>>>>>> For now you should be able to work around it by doing: >>>>>>>> >>>>>>>> env ARCHS='i386 x86_64' macruby_deploy --compile --embed --gem >>>>>>>> rest-client --gem sequel --bs Issues.app >>>>>>>> >>>>>>>> And adjust the actual archs for the ones your app is built for. >>>>>>>> >>>>>>>> On Thu, May 5, 2011 at 11:57 AM, Petr Kaleta <petr.kal...@me.com> >>>>>>>> wrote: >>>>>>>>> Hi everyone, I'd like to deploy my Macruby app using: >>>>>>>>> >>>>>>>>> macruby_deploy --compile --embed --gem rest-client --gem sequel --bs >>>>>>>>> Issues.app >>>>>>>>> >>>>>>>>> but I'm getting this error: >>>>>>>>> >>>>>>>>> *** Deployment started >>>>>>>>> *** Embedding MacRuby.framework >>>>>>>>> *** Embed RubyGems libdirs: >>>>>>>>> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/mime-types-1.16/lib, >>>>>>>>> >>>>>>>>> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/rest-client-1.6.1/lib, >>>>>>>>> >>>>>>>>> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/sequel-3.22.0/lib >>>>>>>>> *** Embed BridgeSupport system files >>>>>>>>> *** Fix install path of binaries >>>>>>>>> *** Fix identification name of libmacruby >>>>>>>>> *** Compiling files >>>>>>>>> /usr/local/bin/macruby_deploy:127:in `block': undefined method >>>>>>>>> `delete_if' for nil:NilClass (NoMethodError) >>>>>>>>> from /usr/local/bin/macruby_deploy:117:in `compile' >>>>>>>>> from /usr/local/bin/macruby_deploy:70:in `run' >>>>>>>>> from /usr/local/bin/macruby_deploy:283:in `<main>' >>>>>>>>> >>>>>>>>> Am I doing something wrong, or this is some bug in macruby_deploy >>>>>>>>> tool? I am using the latest macruby version from origin/master. >>>>>>>>> >>>>>>>>> - Petr >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
