Hi François !
| > While we're at it, don't you think we should build a single file
| > `STUFF' which contains NEWS, COPYING, AUTHORS, THANKS, TODO,
| > ABOUT-NLS, ChangeLog, INSTALL, README etc.? Let's face it: there is
| > plenty of useless files in there, nobody cares!
|
| Somebody cares! Do not generalise! :-)
I was kidding :)
| > We shouldn't distribute the Makefile.am and configure.in too, there are
| > useless for the installer, and waste bandwidth.
|
| Each distribution should give people all what is needed for maintenance,
| or at least, good pointers to re-establish a full context of maintenance.
| Installers, or even users, should not be considered as lesser people.
That's precisely my point, and I consider that your suggestion:
| One big `acincludes.m4' for one package is exactly what a
| package needs.
goes *against* this. `acinclude.m4' is a product, it is not a source.
| As a maintainer, I do not like too many files, or auxiliary directories
| where a single file would do. Fewer files is a measure of clarity and
| simplicity. regex.[ch], malloc.[ch] or gettext.[ch] may be dozens of file
| in their own distribution, but a pair of files is enough for them in mine.
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.
I don't think integrating `depcomp' or `libtool' in `missing' has any
logic. There is a threshold somewhere which guarantees we will never
have a package which will be pure source, without additional logistics
tools. If people want to see something pure,
AC_CONFIG_AUX_DIR(config) is the only answer.
If we want to extend `missing', it should not be a big backpack in
which we put by hand all the tools that might missing. So it should
be modular, let only for us to have something manageable.
But if it is modular in means that there can be several kinds of
`missing' (or different `shtool's), which *again* means there will be
on the one hand the sources of `missing' and on the other hand, the
product, a `missing' with *some* support for missing tools.
Guess what it means? *more* entropy, because we will need yet another
autotool to build `missing'. Unless each package holds a dispatching
script `missing' with many small slaves. This time we would really
distribute what we use. But people will complain because that's
another myriad of files...
I have sympathy for the `too many files' argument, but it's a can of
worms: several independent files will be more manageable (as long as
Automake gives his support). It is also more Free Software, since we
give what we use, not a product which will require that other people
have to install `automissing'.
| > I too, enjoy to polish my package so that it's cute. But this is a
| > minor detail as compared to the runtime existence of the package.
|
| I polish my packages because they are more maintainable this way. Or at
| least, because there is more joy for me working in an ordered environment.
| There is some anality in my work methods, and we are not all alike :-).
I think we share a lot of this love for a clean job, and you're a real
model to me (no flattery in there, pure honesty). But I am concerned
by the infrastructure which might be needed to have something
`cleaner' according to the tastes of the single-file guys. It's going
to be more work for no real improvements IMHO. It's going to be more
entropy. Instead of complaining there are too many files but exactly
the files that are needed, people are going to complain about too big
a `missing', addressing issues they don't need.
The alternative is the one I said: automissing, which means yet
another package to install before being able to play with a package.
Unless `automissing' belongs to Autoconf of course.
My strongest fear is that since people want a single file, we will end
up with distributing products. Let's distribute pure sources.
| > She cares about the present, not the box.
|
| Such reasonings were behind the poor state `tar' once had.
Nah, François, you know I wasn't meaning that. OK, my example was
more extreme than I meant. I'm only saying that using
AC_CONFIG_AUX_DIR leaves a clean package which distributes sources.
Stacking the micro-tools together is another means to have a clean
package, agreed, but introduces a lot (IMHO) of additional burden.
And, again, this won't be enough for the single-file people, since
there will still be ansi2knr, libtool, depcomp, config.* etc. They
will never be satisfy, we just can't!
| C files are variants from package to package.
I was referring to lib/.
| Currently, the growing trend is using one package to distribute other
| packages directly, as such. It just spreads version confusion and complexity
| everywhere. Each thing at its proper place, that would be much better.
This last sentence is my argument too :)
I agree there are too many m4 files now, but Autoconf is guilty, not
the system.
| Just a comment, here. We used `mkdir -p' all along in this thread, but
| I guess it might be better to think `install -d' rather than `mkdir -p'.
Not sure. As far as `autoconf' (well `configure') is involved, there
are places where `mkdir -p' is lacking. For instance to handle
gracefully
AC_OUTPUT(1/2/3/4/5/Makefile)
Akim
