[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] autoconf and autoreconf
From: |
Bernd Warken |
Subject: |
Re: [Groff] autoconf and autoreconf |
Date: |
Sat, 13 Apr 2013 19:38:46 +0200 (CEST) |
> Von: "Bernd Warken" <address@hidden>
> > Von: "Werner LEMBERG" <address@hidden>
> >
> > > I ran `autoconf'. There was a subdirectory `autom4te.cache/'
> > > created. First I just deleted it.
> >
> > This directory and its contents is *always* intermediate! It just
> > speeds up the execution of the autoconf tools. Actually, the
> > `configure' script itself shouldn't be stored in the repository but
> > generated during a `make tarball' call...
> >
> > Please remove it again.
>
> I cannot get it away. I tried it about 10-times. But each update
> of groff CVS on my computer adds each time another subdirectory
> `autom4te.cache/'.
>
The wesite
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Autom4te-Cache.html
says the following:
#####
20.6 What is autom4te.cache?
What is this directory autom4te.cache? Can I safely remove it?
In the GNU Build System, configure.ac plays a central role and is read by many
tools: autoconf to create configure, autoheader to create config.h.in, automake
to create Makefile.in, autoscan to check the completeness of configure.ac,
autoreconf to check the GNU Build System components that are used. To “read
configure.ac” actually means to compile it with M4, which can be a long process
for complex configure.ac.
This is why all these tools, instead of running directly M4, invoke autom4te
(see autom4te Invocation) which, while answering to a specific demand, stores
additional information in autom4te.cache for future runs. For instance, if you
run autoconf, behind the scenes, autom4te also stores information for the other
tools, so that when you invoke autoheader or automake etc., reprocessing
configure.ac is not needed. The speed up is frequently 30%, and is increasing
with the size of configure.ac.
But it is and remains being simply a cache: you can safely remove it.
Can I permanently get rid of it?
The creation of this cache can be disabled from ~/.autom4te.cfg, see
Customizing autom4te, for more details. You should be aware that disabling the
cache slows down the Autoconf test suite by 40%. The more GNU Build System
components are used, the more the cache is useful; for instance running
‘autoreconf -f’ on the Core Utilities is twice slower without the cache
although --force implies that the cache is not fully exploited, and eight times
slower than without --force.
#####
So it seems to be not as bad as it seemed to be. It can be kept for further
runs of `autotools', for example if someone will do `automake'.
Bernd Warken
- Re: [Groff] autoconf and autoreconf, (continued)
- Re: [Groff] autoconf and autoreconf, Werner LEMBERG, 2013/04/13
- Re: [Groff] autoconf and autoreconf, Keith Marshall, 2013/04/13
- Re: [Groff] autoconf and autoreconf, Daode, 2013/04/13
- Re: [Groff] autoconf and autoreconf, Keith Marshall, 2013/04/13
- Re: [Groff] autoconf and autoreconf, Werner LEMBERG, 2013/04/13
- Re: [Groff] autoconf and autoreconf, Ralph Corderoy, 2013/04/14
- Re: [Groff] autoconf and autoreconf, Bernd Warken, 2013/04/14
- Re: [Groff] autoconf and autoreconf, Ralph Corderoy, 2013/04/14
- Re: [Groff] autoconf and autoreconf, Werner LEMBERG, 2013/04/14
Re: [Groff] autoconf and autoreconf, Bernd Warken, 2013/04/13
Re: [Groff] autoconf and autoreconf, Ingo Schwarze, 2013/04/13