1
votes

We maintain a RPM based software distribution at work so that we have a common set of software across all the platforms that we support. As a result we have to build a lot of third party software, and frequently find situations where we need to run autoconf/automake/libtoolize/etc to get it to build on Solaris or another platform.

I've had very mixed results with this. It seems that these tools are fairly brittle and frequently the files only work with the version of autoconf/automake/etc that they were originally written for.

Ideally I'd like to only have to support one version of the GNU autotools, but I get the impression that I'm really going to end up having to have a copy of every version lying around.

Is this unusual, or do other people have the same problems? Is there a subset of the versions of autotools that will cover all cases?

2

2 Answers

5
votes

It is true that autotools can be brittle and version specific. But remember that you only need to use these tools on your development machines. Deploying the project to the target machine doesn't require that any of the tools are installed on the target. Even test machines don't need any of the tools. They are really only need to run when the dependencies change, such as adding additional files or libraries to the project.

We have been using these tools for inhouse projects for many years, and haven't come across a better solution. If you are in a Unix world, don't underestimate the benefit of having a system where configure; make; make install just works.

1
votes

Your experiences are not unusual. Autotools is brittle like that, specially for complex projects. There seems to be no alternative for having a lot of versions of it around, sadly.