Re: [gentoo-alt] handling of newins mylib.so n ebuilds

[Jeremy Olexa]

On 06/08/2010 04:46 PM, Ramon van Alteren wrote:
> Hi All,
>
> I was looking at ebuild dev-ruby/json-1.4.3-r1 for my x64-macos prefix from
> gentoo-x86 and it fails on the following snippet:
>
> each_ruby_install() {
>      each_fakegem_install
>      if [[ $(basename ${RUBY}) != "jruby" ]]; then
>          ruby_fakegem_newins ext/json/ext/generator.so lib/json/ext/generator.so
>          ruby_fakegem_newins ext/json/ext/parser.so lib/json/ext/parser.so
>      fi
> }
>
> This obviously fails because my gcc-apple produced generator.bundle and
> parser.bundle instead of the hardcoded .so 's
>
> I imagine that this problem has been tackled before in other ebuilds but
> couldn't find a good example.
>
> What is the best approach to deal with constructs like this ?
>
> Ramon

Can you use get_modname() from multilib.eclass??

# @FUNCTION: get_modname
# @USAGE:
# @DESCRIPTION:
# Returns modulename with proper suffix {.so,.bundle,etc} for the current
# platform identified by CHOST.
#
# Example:
#     libfoo$(get_modname)
#     Returns: libfoo.so (ELF) || libfoo.bundle (MACH) || ...