On Sun, Jun 23, 2013 at 12:09 PM, Charles Oliver Nutter <head...@headius.com> wrote: > * Remove C ext support to an external repository and gem
I have pushed a no_cext branch that removes all direct references to C ext stuff from src, build/test, dist, and so on. Everything looks clean (and it feels good to remove it). There's also now a jruby/jruby-cext repository that contains everything I removed (except logic for distribution and testing). It *almost* builds :-) I can push no_cext as master any time. How high a priority should we place on making it possible for 1.7.5 to still run C extensions? It has been deprecated for one major release and four minor releases. - Charlie On Sun, Jun 23, 2013 at 12:09 PM, Charles Oliver Nutter <head...@headius.com> wrote: > Ok folks...the branching off of 1.7 is coming very soon, and I think > one of the biggest ticket items we need to do before then is reorg the > codebase like we want to see it in the future. Failing to do this > before branching will massively complicated merging changes back. > > I have a few proposals. > > * Mavenizing. > > I know this will elicit groans from many people, but it has become > more and more of a hassle to keep versions in sync and manage the > repository with all our external dependencies. If we were 100% > maven-based for build, all dependencies would live outside the repo > (not as repo-bloating binaries) and we'd always be able to generate a > current snapshot. I think we need to do this. > > Making this change should eliminate build_lib and much of our ant build > scripts. > > * Reorg upgradable extensions into their own src trees or repositories. > > I'm thinking of pieces like openssl, psych, readline. Some extensions > are already in their own repositories and we just copy them in, like > json. We could proceed with this one of two ways: > > Via maven layout: src/main, src/openssl, src/psych, etc. > > Via separate repositories: jruby/openssl, jruby/psych (or just in > psych proper), etc. > > I'd like to get as many exts and stdlib separated out as possible. > > Making this change could move most of org.jruby.ext.* out of the main > repository and would make managing and upgrading ext and stdlib > easier. > > * Remove C ext support to an external repository and gem > > I'm playing with this locally, and there aren't many dependencies from > JRuby proper back into C ext code. It stands alone pretty well. > > Who knows...spinning it off might make it more likely third-party > folks will continue to update and improve it. > > Removing it will eliminate the org.jruby.cext package and the cext > dir, plus any build and test artifacts related to cext. > > ... > > Anything else? > > - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email