This sounds reasonable to me and is the method we'll go for in Cool Stack. Shanti
Prashant Srinivasan wrote: > Here's a few thoughts on how to proceed with SFWNV Ruby support for > native gems - comments are appreciated. > > Ruby maintains data about it's build information(like compiler > location, linker paths, flags etc.,) in a file called rbconfig.rb. When > the end user installs a gem that includes native code, the stored build > information is used to compile/link the native code. > > Now, with OpenSolaris, the environment that is used to build Ruby is > not available to end users(unless you're in Sun and have mounted the > appropriate nfs locations). > > Hence Ruby needs to be configured with information about a compiler > that is available on the OS installation that Ruby is bundled with. > > Another issue that we've seen is that native gems tend to use $CFLAGS > that are specific to a certain compiler. > > So, in order to make using Ruby as easy as possible to folks with > different preferences, we're considering packaging two versions of > rbconfig.rb, one tailor made for gcc, and the other for Sun Studio. > > rbconfig.rb will be a symlink, and point to the gcc configuration. > This is to make it seamless for a user of native Ruby gems like MySQL, > Postgres etc., to get started without needing to learn about compiler > locations/flags and the nitty-gritty. > > The Studio configuration is for users who tend to have Sun Studio > already installed on their systems - they get to use this by manually > changing the rbconfig.rb symlink to point to rbconfig.rb.sun_studio > > -ps > > > >
