Do you keep your build tools in version control?

Generally I only add items to version control that are likely to be maintained by myself or someone else I work with. An external library is normally consumed by a project - most projects aren't in the business are re-writing the libraries they depend upon.

I would suggest adding tools that you customize to version control. For everything else, you can just save the packages in a common location. No need to bloat your repository with code that will never change from the standard distribution.

We are a Maven shop and previously an ANT shop. In the ANT days we would check dependent libraries into the project structure. Now we only check in the resources necessary to build the application (pom, source code, resources, etc) but definitely no libraries.

We do not - in fact, I've never worked for a place that did.

We do keep things like Makefiles and build scripts and testing scripts in source control, but never ant or C compiler or such.

The reason is, it usually requires more than simple checkout to get the build tool to a usable state, and you need to do some heavy-duty sysadmin job to maintain multiple versions at the same time or switch between versions. So keeping them in source control would solve the tiny part of the problem.

Code, build, test, documentation and any other automation. I generally even put the schedules and any other project-relevant documentation in the repository as well.

And for most projects, if I have the source for dependent libraries, I usually put those in their own repositories, so I can track changes to them over time.

As for pre-package tools in installable packages, I keep them all in one big directory tree on a accessible server (with the old versions). That way I can point any new developers at the dir and tell them what to install (and know that they have the same versions as the rest of the team). I'd use a repository, but it's overkill, and a shared file-system is easier to access by everyone. The old versions are kept in case of support issues.

Paul.

I try to use always virtual machines as the build system.
And store these (in the best case) for each project.

The main problem of using a tarball or a repository with all your tools:
It costs too much time to install them all and then you get always problems to get it working again after some years.

Also downloading via a script or simply tell only the web source is to unstable after some years, you will get some newer release with other features and bugs.

It's sometimes simply fails to install the build system on a newer OS-Version.
Or the newer version of some tools (like Visual Studio 2025) will use other project files and the "full upward compatibility" fails.

Also the licenses are problematic after some years, can you get your new activation key in a reasonable time? Does the company does support it anyway?

Virtual machines simply contains all necessary installed tools and are running after a few minutes.
Nice, especially if I only want to change only a few lines of code.