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


Reply via email to