On Jan 29, 2013, at 3:28 PM, Gary Weaver <garyswea...@gmail.com> wrote:
> I think it would be better to stick with the current DSL looking > "add_*_dependency" type of thing and do a require at the top of the Gemfile > that would load that gem to extend Gem::Specification. > > And since the name and version of the dependency could depend on platform > and tool used to list the loaded libraries, maybe the extending gem should > define command name specific methods, like for OS X that provides 'otool' > as a dynamic library lister: > > spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>= > 159.1.0' > > so that that gem would maybe do: > otool -L `which ruby` > > and then parse that output to find the current version. > > Then, for linux, that gem would use ldd and you'd need to specify: > > spec.add_native_dependency 'ldd', 'libm.so.6', ['GLIBC_2.2.5'] # if array, > it is a list of valid versions (for versions that aren't x(.x)(.x)) As callous as this sounds, this actually doesn't solve anything. The proof is in your examples -- they're a part of the standard library for the respective platforms. As soon as you need something like 'libferrous' of a specific version, you're boned. Also ldd/otool will never output the results of a gem's native dependencies, because ruby is never linked against them until the gem is required, and only indirectly. Ruby loads the gem's native object which is linked against the library that would be in the gemspec. And this is all before we start talking about how to turn 'libferrous' into a set of packages or source to install that would allow you to compile the gem. That's the miasma. -Erik _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
