On Jan 29, 2013, at 3:45 PM, Erik Hollensbe <e...@hollensbe.org> wrote:
>
> 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'
Certainly we don't want to bind to specific tools, nor to particular file
names. Binding to shared library names (linker names) and versions might be
/slightly/ more protable, but it's all fraught with portability issues.
Either way, we should be using native linker libraries directly, not command
line wrappers, to do support discovery.
>> 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))
Right now, this can all be done, and is done, in extconf. It's more portable
than writing specific native code for each linker and loader, as it just uses
the platform build tools to perform assertions. Problematic and inefficient as
they may be, autotools work this way for this same reason. Maybe today we have
few enough supported platforms that it's viable to write code that links the
linkers, without a totally horrific combinatorial explosion of native code, but
later, not so much.
In order to write the native code under discussion here, would require rubygems
to have C code, which is against the current approach. If we could have native
code, there are plenty of inefficiencies and other problems we could probably
solve for many users. It's additionally worth noting that none of this
discussion has yet considered the JVM, which further has potentially a
multi-platform implication, if you're using a combination of native libraries
and JNI. At this point you may find yourself wanting to assert the JVM like a
platform, and the native platform itself. We already see issues in this area
around RUBY_PLATFORM = "java", where "platform" is insufficiently defined for
people.
> 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.
% otool -L nokogiri.bundle
nokogiri.bundle:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version
9.15.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version
3.26.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version
10.8.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version
7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
228.0.0)
> 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.
This.
>
> -Erik
> _______________________________________________
> 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
