Autotools fun

Forum: DSL Tips and Tricks
Topic: Autotools fun
started by: curaga

Posted by curaga on June 30 2008,15:45

Whenever you do some more compiling, and most stuff has the autohell *cough* autotools *cough*, you will exactly know what I'm talking about - nothing has changed since the last package 1 minute ago, yet you have to wait for it to check everything. So annoying.

Checking you have gcc.. yes (oh really)
Checking your gcc works.. yes (ooooh)

and so on. Well folks, I have a solution

I thought I should use the cache for my advantage. So I configured a simple package, removed anything I might possibly change from the config.cache (install prefix and optimization flags), and now I copy this file whenever I compile anything and have a huge speed boost in configuring.

Quote

Why a simple package? Wouldn't a complicated one give more speedup?

Why yes, thanks me for asking. The thing is, only the simple parts are almost guaranteed not to change. So the thing is being sure the cache screws nothing up.

Especially for older comps, as the config phase can take longer than the compiling :;):

.

So, first time with a simple package (I used popt):
./configure -C

Then edit the config.cache by removing lines you might change.

Then, whenever compiling anything, copy this file there and give -C to configure and it will load the cache and not check anything that's in there.

Posted by mikshaw on July 01 2008,02:40

Quote

Why a simple package? Wouldn't a complicated one give more speedup?

Whoever you were quoting needs to be slapped =o)

I honestly don't understand what you're saying, apart from the fact that I too see it as being a waste of time to check for things I know I already have. I guess it will require an actual use to see what you are doing.

Posted by ^thehatsrule^ on July 01 2008,03:35

Quote (mikshaw @ July 01 2008,02:40)

Quote

Why a simple package? Wouldn't a complicated one give more speedup?

Using the cache will allow you to skip certain steps that are checked during configure. From what I understand, those steps that would be skipped are the ones that have the same configure check.

The quoted question is relevant. If a package that has many dependencies, etc. that are checked for, a larger configure cache will be generated and one can conclude preliminarily that it would cover more checks in other packages, thus speeding things up even more. However, the actual checks can vary from package to package, etc.