Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When we try to ./configure some Linux software from source before makeing it, usually there is a huge list of checking other software parameters performed, for instance the below is a tiny part of such a long list:

-- Java Home guessed: /usr/lib/jvm/java

-- Found ANT: /usr/bin/ant  
-- Building libhdfs
-- Could NOT find MPI (missing:  MPI_LIBRARY MPI_INCLUDE_PATH) 
-- MPI Not Found! Distributed Executables will not be compiled
-- Looking for pthread_setaffinity_np
-- Looking for pthread_setaffinity_np - found
-- Performing Test HAS_MARCH_NATIVE
-- Performing Test HAS_MARCH_NATIVE - Success
-- Performing Test HAS_MTUNE_NATIVE
-- Performing Test HAS_MTUNE_NATIVE - Success
-- Performing Test HAS_CRC32
-- Performing Test HAS_CRC32 - Failed

I have always been surprised by this huge list of checks - are they really all necessary? In many cases some conditions are Failed - like the last line of the example - however the configure continues successfully, so this means they were not necessary?

share|improve this question

Some of the tests are historic. In some cases the software package is really old and has been around long enough that they tried to build on old systems that didn't have all the resources that we have now. But you might as well leave these old checks in - it doesn't cost much in the way of size.

Some of the checks are for multiple ways of doing things. If you can do something with A or B, then you check for any of those. The check for A may fail, but then the check for B succeeds, and you use B just as well.

And some of the checks are for optional things. If there is a feature X that isn't necessary but a "cool to have" then you can check for X, and include that feature in the build if you can, but leave it out and have a serviceable package (without X).

Then some features are truly necessary, and any failure will abort the package build.

So, it really depends on the feature; are there alternatives, and do we really need this or is this a "nice to have".

The other thing to consider is that the configure is pretty much run once, at build time. Any extra configure steps are just that one time, and don't affect runtime in any way at all. You may wait an extra 5 minutes at configure, but that's it. It's usually not a bad tradeoff in extra steps/trying to make a more stable build.

share|improve this answer

Are them really necessary?

That depends per program, but usually most of them are not needed.

The real idea is to check for a preferred program, and if it is not available to fall back to an alternat. E.g. check for ncurses, if present: use. If not present then check for the normal curses library. If present, use that, if not not check for the next alternative or abort.

The idea behind this is great, but the implementation is usually flawed. Too many people copy the autoconf and/or configure scripts from other programs and just add stuff until things work. That includes a lot of cruft.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .