Re: autoreconf --clean

[Bob Proulx]

David Byron wrote:
> Bob Proulx wrote:
> > The 'make maintainer-clean' automake generated target will almost do
> > what you want.  You could add the additional files to the variable
> > MAINTAINERCLEANFILES and then everything would be cleaned up.
> 
> Right, but then I need a Makefile (which I might not have if I've run
> autoreconf -fvi, but haven't configured anywhere),

I think once you have run autoreconf --install that it is not much
more effort to run ./configure to get a fully working system.  But I
am not saying this to talk anyone out of an autoreconf --clean option.
Conceptually it is nice symmetry.

> and I need to add some special logic to the Makefile which I bet
> duplicates info that autoreconf already knows,

I bet it does not really know this and that it is actually spread out
into many other places.

> > What use model are you envisioning?
> 
> It's helpful when preparing to check things in to revision control to remove
> _all_ generated files.

What version control system are you using?

I am using to use CVS, SVN, and GIT and all of those will report files
that will be committed next.

  cvs -qn update  # aka 'cvs -qn up'
  svn status      # aka 'svn st'
  git status

> rm -rf does this, but is a little more brutal than I have in mind.

I was asking the use model why because I could not think of a reason
to do this myself.  I am still not sure of the utility of this.

> This makes sense but what if we assume that we're starting with configure.ac
> and Makefile.am instead of a configure script and Makefile.in?  At this
> point the source directory can no longer be read only, correct?

Hmm... I think that is correct.  But the configure script and
associated files are designed to be platform independent.  Therefore
they would only need to be created once and could be used for all
other platforms.

With your last bit there that explains why you want to have run only
'autoreconf --install' but not configured there.  I understand now.

If I were to brainstorm something that is not very well thought out I
would suggest creating a symlink farm from a build area into your
read-only area.  Then you could configure in your build area and all
files would be referenced from your read-only pristine source area.

Bob