Yeah, that's always an option - multiple build tools in one repo. If that's the direction we go, I'd advise a clean separation of code - i.e., java code in one place, python code in another, so there's only one way to build a given directory. And then use make to glue things together for a "full" build.
A. On Wed, Sep 23, 2015 at 9:49 PM, Nick Dimiduk <[email protected]> wrote: > I can't say I'm a build expert, but here's a project I did a while back > that mixed python and Java. > > https://github.com/ndimiduk/tilebrute > > On Wed, Sep 23, 2015 at 10:40 AM, Andrew Bayer <[email protected]> > wrote: > > > Hey, build stuff! My niche! > > > > So...make or Gradle are my two thoughts. Maven is a shitty option for > > anything but Java. Make is old school and all, but it Just Does What It > > Says It Will, which is nice. Gradle is, IMHO, problematic for Java > projects > > due to how easy it is to due weird non-standard things with it, but in > this > > case, we are kinda looking for exactly that. So. > > > > One advantage to Gradle is that it does Java builds. Because if we have > to > > build Java, we are going to end up invoking Maven or Gradle (or, shudder, > > Ant) eventually anyway, whether we are building with Make or Gradle or > > whatever. So cutting out the middleman has virtue. > > > > On Wednesday, September 23, 2015, Allen Wittenauer <[email protected]> > > wrote: > > > > > > > > Hey hey hey. > > > > > > One of the big decisions that needs to be made relatively > quickly > > > is what sort of build tool layout we want to have for the various > > > components. Sean and I have been discussing this topic I think for > > > probably a month now but never came to any firm decision. [This is > > > particularly relevant to YETUS-2, YETUS-6 and YETUS-15.] Let me see > if I > > > can summarize all of the highlights… I’m sure Sean will add whatever I > > > forgot. :) > > > > > > * It’s extremely important that we be able to test Yetus with Yetus > ASAP. > > > (I hope this is obvious… *smile*) > > > > > > * Given our multi-lingual needs (Java, python, & bash as of today), > > > different components may need different build tools. > > > > > > * Avro is a lesson of what happens when there are too many independent > > > build systems. > > > > > > * Today, Yetus does not support multiple build tools in a single > project > > > easily or perhaps at all. [That’s a future project. ;) ] > > > > > > * One of the founding principals is to keep things as highly portable > as > > > possible. This indicates ‘make’ or a common derivative (e.g., autoconf) > > as > > > highly desirable. Plus there is a good chance that the Yetus community > > at > > > large is going to be more familiar with make over every other tool. > > > > > > * Recursive building is a huge …. but is an anti-pattern in make. > > > > > > * Today, Yetus has support for ant, gradle, and maven, with maven > support > > > being the strongest and gradle support being the weakest (things like > > > checkstyle are just flat out not supported yet). Adding support for > make > > > is on the list but not there yet. > > > > > > * Maven is likely to be the ‘fastest’ for us to bootstrap and be > > > productive with: annotations already has a pom, we already know how to > do > > > bats-based unit testing for the bash code, mvn site support, recursion, > > > etc, etc. But longer term, it may not be the ‘best’ solution and the > > > learning curve for folks is particularly high. So there might be an > > > (expensive) build tool switch later on. > > > > > > * There is still the whole “what does a release artifact look like?” > > > discussion that will likely have an impact on the build tool. But that > > > should be a relatively minor concern. I hope. > > > > > > * Who has the cycles to build the build bits anyway? > > > > > > > > > Anyone have any thoughts? Opinions? Thanks! > > > > > > > > >
