Eric Hodel wrote:
> Gem::SourceInfoCache.cache_data[...].source_index.map { ... }.uniq
Dude! You Rock!
> Don't forget Universal.
Noted.
> It should all be in Config::CONFIG under the TARGET_* values. Ruby
> implementations should put sensible values in there. (I've already
> talked with Charles Nutter on this, and I think they've changed
> JRuby's values to be more autoconf-compatible.)
The tattle data includes this data and is very interesting. But I'll
comment on that in a separate thread.
> I'd rather have everything spelled-out since that's easier to read,
> mygem-1.0-Universal-MacOSX-10.4. (Is there a defacto standard for
> naming packages like this?)
Hmmmm ... makes for *really* long file names, but I agree. I would
probably not do the mixed case thing tho.
The only standard that I'm aware of in this space is the triple of
hardware-vendor-os from the GNU autoconfigure stuff.
> RubyGems shouldn't allow gems to be indexed (repository side) if
> their names don't match their internal metadata.
You're right. Any other choice would probably be regretted in the long
run.
> I think the override should apply to all gems installed, rather than
> only explicitly listed gems. There's at least one Rubyist who has
> gems installed on a disk shared by multiple machines.
Ahh, I was thinking of the one-off case where a particular choice was
made one a single gem that didn't work for some reason. I think your
use case is more along the lines of a cross platform install, which is
an important use cose. So noted.
> Also, this change might require changes in the local gem directory's
> name, mygem-1.0-Universal-MacOSX-10.4 instead of mygem-1.0 to allow
> cross-platform gems to live side by side.
I think it does that now. I just installed the x10-cm17a gem for
msinw32 (on my Mac ... heh) and it included the platform name in the
gem directory.
--
-- Jim Weirich [EMAIL PROTECTED] http://onestepback.org
-- In theory, practice and theory are the same.
-- In practice, they are different.
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
