On Oct 23, 2010, at 1:30 AM, Tomas Matousek <tomas.matou...@microsoft.com> wrote:
> I don’t understand how three distinct github repos that I need to map into > some directories on my disk whose relative location to each other is > hardcoded in some scripts in each are better than a single repo that has a > well-defined structure. > You are speaking like someone responsible for both languages and the DLR. I'm making a suggestion as someone really only interested in IronRuby. The repo isn't called "DynamicLanguages", it's called "IronRuby", which is at best confusing. If only git had some way to define a link to another repository as some sort of sub module... As a Rubyist I'd like to run a rake task to build to each defined target and run the RubySpecs. It wouldn't replace xbuild, just automate it. I don't understand the pushback to this idea. Why not make a dedicated repo for IronRuby free of the ancillary projects and geared to someone like me? And likewise make the IronPython repo friendly to our Pythonic friends? > The amount of code you need to know depends on the part you contribute to. If > you work on IronRuby libraries you don’t need to even look at IronPython. It > is indeed better to look there because similar functionality might already be > implemented there. For example, if you worked on FFI you might want to check > out IronPython’s CTypes and perhaps reuse some code. Why would you need to > understand the entire code base if you needed to do a local change? Just > don’t look where you don’t need to J. Building IronRuby is also simple – you > just run xbuild Ruby.sln from Solution directory. Subsequent builds are > incremental, so you don’t even need to build everything if you don’t change > core components. I don’t see how this could be any simpler. > Unfortunately I do see how this could be simpler.
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
