views:

222

answers:

4

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?

+1  A: 

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.

Leon Timmermans
+2  A: 

It is true that autotools can be brittle and version specific. But remeber 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 unix world, don't underestimate the benefit of having a system where configure; make; make install just works.

KeithB
A: 

@KeithB

As I stated in the question, the issue isn't for software we develop in-house. The problem is more situations like this: 3rd party software where a buggy version of libtool was used, and doesn't work on SPARC systems, and we need to regenerate with a new version of libtool. This requires we find a combination of autoconf, automake and libtool that can build properly on that platform.

We do use autotools for software we develop in-house, and that's a much more controlled situation where we have better luck.

dvorak
A: 

What do you think of some alternatives to autotools? cmake or scons?

Amit Kumar
Given that his problems are with 3rd-party programs, that's not really an option.
Branan