DEV Community

Nicola Apicella
Nicola Apicella

Posted on

Multi-language build tool?

The beauty of a multi-language build tool is that it abstracts away the language specific build logic. So if a service uses golang and Java for the backend, and javascript for the front-end, developers working on the project, won't need to learn all the different ways to build it.
It's a standardization which makes development faster.

I have been looking for open-source multi language build tools.
I have tried Bazel and Pants, and looked briefly into Buck.

They all work fine for a mono-repo, but they are cumbersome to use when the code spans different git repos.

Do you use a language agnostic build tool?
Which one do you use? How do you organize the code in this case?

-Nicola

Top comments (16)

Collapse
 
phlash profile image
Phil Ashby

I'm officially a Luddite and still use GNU/make for most of my little experiments, and even some quite big ones. It does the thing a build tool is supposed to do - reduce cycle time by taking the minimum number of actions required to bring the outputs up to date - and it does it well.

I've used a few opinionated, language-focussed tools like Maven, Ant, Cargo, etc. Finding that they are effective for their little world, but painful outside - this may be a conscious decision of the creators to lock you in... I'm not a fan of learning Yet Another Build DSL (YABDSL?) like pom.xml syntax either.

I'm not so sure about meta-build tools (CMake, SCONS, Autotools, etc.), they frequently seem to be to abstract / genericised and frankly weird to bother learning, certainly they are a nightmare to debug!

Collapse
 
therealkevinard profile image
Kevin Ard • Edited

It's NOT just me?!?! Google sent me here when I asked for a multi-language build. I'm using Makefiles now, and suspected there was something more. Bazel is the front-runner, of course, but... Idk... Make has got me pretty far.
I mean, everything ships with a build system - just need to coordinate the triggers across packages, and maybe slide in some variables here and there.

Well, make does THAT.

Collapse
 
napicella profile image
Nicola Apicella

Thanks for sharing.
I have used make mostly for Golang projects.
But Go already ships with a full fledged build tool, so it is fair to say that for Golang builds, make it is just a tiny wrapper.
I haven't used it for anything else because language specific build tools (like the ones you mentioned) also ship with dependency management systems, which is super convenient.

I understand you used make for Java. What did you use as dependency manager? Apache Ivy?
Can I ask you to share a project in which you did that? :)

Collapse
 
phlash profile image
Phil Ashby

I understand you used make for Java. What did you use as a dependency manager?

I have used make with Java: github.com/phlash/java-sdr/

but no dependency manager there, all three deps simply get a mention in the Makefile. That was a number of years ago, these days I would probably use Git submodules (I probably still should for that project!)

Thread Thread
 
napicella profile image
Nicola Apicella

Thank you :)

Collapse
 
peterpjaspers profile image
peterpjaspers

You could have a look at tup and at the paper that describes the ideas behind it. This paper is the first one that I have seen that describes the architecture of a language agnostic (and therefore a multi-language) build system. It also describes some serious usability issues present in the various make variants. Tup has an active user community.

Collapse
 
ben profile image
Ben Halpern

I love this in concept, but I fear the build tool space is so much like herding cats that I'm not sure I have high hopes on anything that tries for solid standardization.

Or am I being too cynical here?

Collapse
 
napicella profile image
Nicola Apicella • Edited

It is hard.
On the other hand solutions like Bazel (developed and used by Google) and Buck (Facebook) get pretty close to it.
I mean, they are not interchangeable but once you have picked one you can use them to build basically any language.
I think, at the scale of those companies, you cannot really let each team decide if they are going to use Maven, Gradle or Ant for Java because that would cause an explosion of different build strategies.
So main reason for using them is reduction of cognitive burden, but also the technical one, since it is not always simple to integrate a package build with X with another package build with Y.

Collapse
 
helpermethod profile image
Oliver Weiler

I use Gradle. Gradle may be hard to master but is flexible enough to cover almost any scenario one can think of.

Collapse
 
napicella profile image
Nicola Apicella

I wonder how it works for javascript code bases. I ll give it a try. Thanks!

Collapse
 
cjbrooks12 profile image
Casey Brooks

I recently found a Gradle plugin which hooks node scripts or node build tool tasks up to Gradle tasks. It works pretty well from my initial usage of it!

Thread Thread
 
napicella profile image
Nicola Apicella

It looks really promising. Thank you very much!

Collapse
 
evanoman profile image
Evan Oman

I was going to mention Gradle as well. We use it for JVM projects (obviously) but we have also used it for cross-platform native builds (C/C++).

Collapse
 
brburzon profile image
Brandon Burzon

I think you can use "make" together with a Makefile for each projects to tell it how to bootstrap, build, test, or deploy your apps. Not sure if it would be an elegant solution though πŸ˜…

Collapse
 
sasdeployer profile image
Sal

Have you tried this one?
github.com/AuditDeploy/Builder