In the list of things that we ought to do to de-correlate Automake from Autoconf, there is the problem of the list of files to remove for distclean. For instance, a recent bug report is about the configure.lineno that configure might create if the shell does not support $LINENO. In this case, Automake ``forgets'' to remove that file.
Of course, I don't think that Automake should know about this file. In fact, I don't think that Automake should know about any file created by configure, rather it should ask configure to perform the tasks related to these files. So I think we should have something like ./configure --clean, or ./config.status --clean. * configure or config.status? It seems much simpler to do that in config.status, since, for a start, it knows exactly what files were created. configure should run in full before knowing what were the created files, hence to be able to remove them, since there can be runtime decisions. But configure is always there, while config.status might not exist. Of course we can have both. config.status --clean would really remove all the files it created, and configure would remove all the files it can possibly create. * top level only? Is distclean valid in a sub Makefile? What is the semantics then? Should it apply to the whole tree, or just the subtree? My opinion is that it makes sense only in the top level Makefile, were ./config.status resides. Therefore, the Makefiles would invoke ./config.status only at the top level. I think this is a good news, and it makes make distclean more robust to interruption: until ./config.status is really run, the Makefiles are still present. I guess I'm not the only one who had a distclean fail at some point, but then it cannot continue, as it relies on Makefiles which have already been distclean'ed. There are probably other questions to ask, but let's go step by step.
