On Tue, Feb 3, 2015 at 6:32 AM, Dominic Evans <dominic.ev...@uk.ibm.com>

> Rafael Schloming-3 wrote
> > These projects aren't actually quite as independent as they look. There
> is
> > a common test suite that runs against both implementations to help keep
> > them in sync with each other. This is the python test suite that lives
> > underneath the top level tests/python directory.
> > These tests have been integrated into the maven build via jython so that
> > the whole java build looks like a normal maven build and java developers
> > don't need to deal with cmake or getting jython themselves or anything
> > that's outside of the normal java experience.
> >
> > Likewise, the cmake build will detect if java is unavailable and opt out
> > of
> > building the java code, so it's easy for C developers to pretend that
> Java
> > doesn't exist. It also does this for all the different bindings, e.g. if
> > perl or ruby isn't installed it will not attempt to build them.
> This quoted part of the explanation is a little confusing in the context of
> the rest of it.
> It seems that it should be (and already is) a continuous-integration
> requirement that the common test suite (python+proton-c and
> jython+proton-j)
> passes across the whole repository before code can be delivered/committed.
> But unless you change the defaults so that they enforce that both proton-c
> and proton-j are built and the full suite is run by default on all entry
> points (either maven or cmake) then breaking changes are more likely to
> slip
> through the cracks.

I guess what I didn't explain above is that there are two distinct use
cases for the build system. One being as a build/test tool for the those of
us who develop proton, and the other being as a means for end users to
distribute/install proton (or for intermediate users like packagers). For
the former case, you're right it would make sense to have everything be
required. For the latter case having everything be required all the time
would just make it annoying for people to get the part they want installed.

I suppose we could change up the defaults so that building the tests turned
on all the optional dependencies. Then as developers we'd pretty much be
forced to test everything in order to test anything, but as an end user who
doesn't bother building the tests, you would have a much more minimal set
of required dependencies.

We could also just make all the optional stuff required by default on
master and then toggle it to be optional for releases.


Reply via email to