On May 14, 2011, at 1:13 PM, Luis Lavena wrote: > On Sat, May 14, 2011 at 4:46 PM, James Tucker <jftuc...@gmail.com> wrote: >> >> [snip] >> >> I did this to save a huge amount of wasted ram and memory fragmentation. >> http://blog.ra66i.org/archives/2011/02/rubygems-no-longer-chews-on-ram/ >> > > Aha, good, so what should I use then? > > Not all the gems have a manifest file that I can use to know what to > copy from it. > > I don't want to copy any gem compilation artifacts since I'm > comsolidating the contents of the gems to reduce the LOAD_PATH.
Everything in Gem.lib_paths. Builds are copied into lib in the standard mkmf system. > On a sidenote, having files showing these incomplete information is > useless, or having README.rdoc or bin/* files there since Gem.bin_path > already provides access to the binary files. That's forced by specification defaults, and should probably be adjusted. > Would really appreciate a workaround to this without the need to open > the gems and read the yaml directly. It'd be nice to not have to corrupt the gemspecs to do this. Ideally, what someone would produce is a more minimal artifact for the purposes of setting up the load path, shared path, bin path and dependencies. Ideally this would be created on install and removed on uninstall, and replace the usage of gemspecs at runtime. Careful coordination is required to still support gem list -d, etc. > > Thank you. > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exupéry > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
