Status

[dkrikun]

Hi, is tundra actively maintained?
I came across this while looking for a decent build system, and it looks tundra is not being discussed too much.

[leidegre]

Give it a spin. I've used tundra actively for years. I think you'll find the Lua frontend very flexible. It's quite easy to get tundra to do whatever.

For example, I script the project generation with tundra, so that projects (build units) are generated based on convention. This is something you can implement in the Lua frontend yourself. Of course, if you don't need stuff like this, you don't have to.

I think tundra is good for what it does. That is, builds tools, generates code, and then builds more stuff all the while minimizing unnecessary rebuilds. I don't believe tundra needs more features. But patches do happen and the occasional bugfix is merged. Yeah, if you encounter an issue there are people here who both care and want tundra to continue to work.

[dkrikun]

There is this post from 7 years ago, do you know if the plans "towards Tundra 2.0" have been implemented?

https://deplinenoise.wordpress.com/2012/09/30/looking-towards-tundra-2-0/

[leidegre]

@dkrikun yeah, what you see in master is 2.0. 1.0 is in a different branch.

I've been using Tundra since 1.0 and the 2.0 release brought with it some nice performance improvements and simpler ways to extend/script the build pipeline.

I put my implicit build script in a gist if you wanna take a look https://gist.github.com/leidegre/c3a888882eda043915d307b5241fa983

What you need to understand is that when you use the tundra file system API, it creates a cache based on file system modified date and time values (can be configured to use content digest if you want). And that it fully expects that your build setup script is deterministic.

When tundra see that you didn't touch the config file, it doesn't even run the Lua script engine. It just goes directly into building out of date dependencies. This code path is the common use case and it's an incredibly fast code path.