We don't actually try to build all the source code with a single build system. In the interests of being as friendly as possible to various different user communities, we have multiple points in the tree that can be viewed as "top level entry points":
The proton/proton-c directory is the top level entry point for C and it's laid out pretty much how any C developer would expect a C project to be laid out. If you only care about the C code and its various language bindings you can check out the codebase from there and pretend Java doesn't exist. The proton/proton-j directory is the top level entry point for Java and it's laid out pretty much as any Java developer would expect. (At least that is the idea modulo ant vs maven.) If you only care about the Java code you can check out the codebase from there and pretend Java doesn't exist. The proton/tests directory is the test suit for validating that both implementations behave the same, and it too can be checked out independently. The top level proton dir is really the project entry point as project developers are expected to keep proton-j and proton-c consistent with each other and so would always check out and test against both implementations. Right now there is just a barebones config.sh to aid in this, but I expect we'll probably add scripts for invoking the java and C build systems and running all the tests against the artifacts. --Rafael On Mon, 2012-07-23 at 15:40 +0000, Steve Huston wrote: > Exactly. Thank you, Andrew. > > On 7/23/12 11:40 AM, "Andrew Stitcher" <[email protected]> wrote: > > >On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote: > >> What do you mean? I don't know what the proton devs would need to do > >> to support cmake -- the deliverables would be the same regardless of > >> the build system, or can be made to be identical. > > > >I think you are talking at cross purposes here. > > > >Steve is pointing out that those who work on the code base would have to > >learn to use another build system - maven. Irrespective of whether you > >can make its output identical to the cmake it's another thing to learn > >to work productively on the code. > > > >I think that Joseph is talking about the impact on developers who are > >using that code. > > > >I would point out that in the case of C code using maven brings a very > >large build dependency (java) that isn't the case for cmake. Obviously > >if you are building java that isn't important since you must have java > >anyway. > > > >Also cmake is not just a build system, in the comparison with autotools > >(autoconf and automake) it covers both configuration and build. I don't > >know enough about maven to know if it similarly covers both of these > >roles. I'd suspect given its java heritage that it is much weaker on the > >configuration aspect if it supports it. > > > >Andrew > > > >> On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston <[email protected]> > >>wrote: > >> > Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and > >> > autoconf, but that's got a limited lifespan). It would be nice to > >>limit > >> > the number of build systems we need to maintain. I know proton is not > >> > Qpid, but the knowledge and setups needed is one more thing C++ devs > >>would > >> > need to take care of if working on proton. Is there any support on the > >> > proton devs part of using cmake for the C++ part? > >> > > >> > -Steve > >> > > >> > On 7/23/12 9:41 AM, "Joseph Ottinger" <[email protected]> wrote: > >> > > >> >>I was wondering if it'd be valuable to convert the build for proton to > >> >>maven. It's not a "rocket surgery" conversion - it involves moving > >> >>files and just a touch of configuration - but at the same time, > >> >>there're a lot of benefits. > >> >> > >> >>For better or for worse, there're two dominant build systems in Java; > >> >>one is Ant, the other Maven. Maven is winning, because Ant's not > >> >>*really* a build system - it's a scripting engine that people use for > >> >>builds, while Maven is a build system for realz, yo. Maven means a > >> >>regular lifecycle for the build, including explicit testing, > >> >>packaging, distribution phases; ant allows those things but doesn't > >> >>help you create them, and Maven has standards for them. > >> >> > >> >>Maven's set of tools is also very useful; again, you can do the same > >> >>things with Ant if you try, but few developers really care a lot about > >> >>having done stuff in the build system. They'd rather focus on the > >> >>project, not the build. With Maven, we can slap Arquillian into the > >> >>build (for example) and have a full module/integration/system test as > >> >>part of the build process, instead of bolting such things into place. > >> >> > >> >>Maven's also cross-language. Proton isn't just Java, of course; Maven > >> >>means we can use C++ and still have only one build process (within > >> >>certain reason; I'm not claiming Maven's the equivalent of autoconf, > >> >>because duh, but then again, autoconf is SOOOOO much fun....) > >> >> > >> >>I'm more than willing to convert the build over if desired; the java > >> >>part's already done, I'd still need to do the C++ conversion but it > >> >>would be pretty easy. > >> >>-- > >> >>Joseph B. Ottinger > >> >>http://enigmastation.com > >> >>Ça en vaut la peine. > >> >> > >> >>--------------------------------------------------------------------- > >> >>To unsubscribe, e-mail: [email protected] > >> >>For additional commands, e-mail: [email protected] > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> > >> > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [email protected] > >For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
