C
Caspar Florian Ebeling
I'm just thinking about how well suited RubyGems might be
to manage non-Ruby packages, as a quite portable generic
package manager. So these would be probably autoconf
style native things which get exclusively used by a ruby
application layer. With ruby C extensions linking into underlying
libraries. Has anyone gone this road and maybe wants
to share some insights on this? Is it more pleasure or more pain?
The alternative would be having parts of a complex application
in some kind of package manager, and our own gems
silently expecting them to be present, without any control
over versions and these things. Unfortunately neither ebuild,
nor debs, rpm, or anything else (at least somewhat) well-known
works across major POSIX platforms, or even only Linux
flavors, if I'm not mistaken.
Cheers,
Florian
to manage non-Ruby packages, as a quite portable generic
package manager. So these would be probably autoconf
style native things which get exclusively used by a ruby
application layer. With ruby C extensions linking into underlying
libraries. Has anyone gone this road and maybe wants
to share some insights on this? Is it more pleasure or more pain?
The alternative would be having parts of a complex application
in some kind of package manager, and our own gems
silently expecting them to be present, without any control
over versions and these things. Unfortunately neither ebuild,
nor debs, rpm, or anything else (at least somewhat) well-known
works across major POSIX platforms, or even only Linux
flavors, if I'm not mistaken.
Cheers,
Florian