| [`configure'] is also a product. Yet, we do not distribute the full
| Autoconf and Automake within each distribution. What is needed for easy
| maintenance is at least some good access to sufficient Autoconf (and
| Automake) snapshots, turned into fetchable distributions (probably not CVS).
Yep, so we really need an additional tool.
| > Agreed, as long as it is automated, and logical. I don't think gluing
| > all the m4 files together in a big acinclude.m4 has any logic in it.
|
| It has the same kind of logic that made `acgeneral.m4' and `acspecific.m4'
| more manageable so far, than a lot of micro files holding one AC_DEFUN each.
| Unless you feel like changing that as well? :-)
As a matter of fact, I do :) Yet there is `aclang.m4' which was
split, but I plan to `acfunc.m4', `actype.m4' etc.
And really, I think it is a different matter. acgeneral.m4 etc. are
part of a single project and no one needs part of it, and change a
macro etc. But m4 files are the way people factor their tests, some
of them perform tests nobody else will. Some people wrote macros that
interest other people, so it is a good thing, IMHO, that the macro be
grouped by modules, and one modules is one m4 file.
Sure today there are too many, and the culprit, Autoconf, is trying to
catch up. But there cannot be a single distribution of all the m4
files: there are just too many different tests, and people want to
keep the control over their files.
| > AC_CONFIG_AUX_DIR(config) is the only answer.
|
| It is the only answer to a problem declared inescapable. We may put
| that answer aside, at least as a way to force us into looking at the
| problem again. We lived a long time without AC_CONFIG_AUX_DIR.
AC_CONFIG_AUX_DIR is older than Automake, it's in Autoconf since 2.0.
| You can create a big rug, and put a lot of dirt under it. It's dirt even
| when well hidden under the rug. Let's forget the rug for a few jiffies,
| and try to see how things could be more clean.
I still don't know whether we are talking about the same thing: are
you referring only to replacement tools (such as mkinstalldirs,
install-sh), or also to tools like depcomp, libtool etc.?
I would like to state my point again, because I feel I've not been
clear.
There is a zillions of files we will never merge together,
such as texinfo.tex, ansi2knr.[c1], depcomp, libtool, INSTALL,
config.*, etc. So whatever the efforts we will put in it, the
people saying there are too many files will *never* be happy.
Merging `mkdir -p' into missing makes sense, yet this is only
two files which we will move into `missing'. So these people
can only be satisfied by using AC_CONFIG_AUX_DIR.
| > Nah, François, you know I wasn't meaning that. OK, my example was
| > more extreme than I meant.
|
| Use more moderated examples, then. It also makes the conversation easier.
| I do not even feel like replying to hyperbolic arguments...
In fact you read it in a different way than I did, my example was
*not* more extreme than I meant, but I took the typical risks of
metaphors: if they fail, they fail badly, but if they succeed, you
found a way to say easily something hard to express :).
Keep happy too, François.
Akim
