>> Akim
> François
>> Honestly, I see no difference between plenty of small utilities and
>> one big.
> Oh, each supplementary file we distribute is a bit of a burden to
> the maintainer (Auto- tools could help here :-), but more
> importantly, one more bit of pollution each time the maintainer does
> `ls' in his/her work files.
Seriously, there will always be several files, yet because it doesn't
make sense to have config.guess, config.sub swallowed by `missing' or
something else. That would be a stupid thing to do IMHO.
>From the very beginning I was annoyed by the amount of files I had to
include in our packages, but soon found AC_CONFIG_AUX_DIR, and that's
way enough.
Let's not forget we are talking about package to build, this is not
related to the software once it is installed, so losing time on this
seems of little interest to me. If a user complains of the little
files there are, she only has to create a config/ directory and voilà!
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! We shouldn't
distribute the Makefile.am and configure.in too, there are useless for
the installer, and waste bandwidth.
This is just to say I see no difference between all this files, but I
doubt anybody will want to put all these files together. I certainly
do not want to see `missing' swallow `libtool', I doubt `missing'
should deANSIfy, I'd be full of admiration if `missing' could bring
`texinfo.tex' with itself, `missing' shouldn't know how to compute
dependencies etc.
This is a consequence of the approach we chose with the Autotools:
We cannot expect to find the tools we need on the user side,
so let's bring our environment with us.
We will *never* be able to make packages that are clean, unless we
decide we support POSIX hosts and nothing else. I find it extremely
unconscious and selfish from people who come to Automake and Autoconf
because they ease their portable life to come and say ``hey man,
there's too many shit in there''. We do our job the best we can, we
face the hostility of numerous factors to design *maintainer* tools,
so really there is a lot of luxury in the idea of having a single
wells and bhistles integrated tool (and God knows I like those tools
though :).
What I'm trying to say is that I don't want to take into account the
opinion of people who come and say ``there's too many files'', because
that's not a measure of anything. Heck, if they don't want to see
them, there is AC_CONFIG_AUX_DIR! They don't even have to pay
attention to anything: Automake does everything!
If *we* want to have a single tool, because it eases our lives, let's
go for it. If we can have a single tool which handles this or that
for free, let's do it.
But personally I don't consider having a single tool is for free: it's
going to be a huge bizarre thing because the tasks to address are very
different. Small tools make more sense, and in addition, this is our
culture!
This is why I insist so much about `shtool', because it (seems to)
integrates the two aspects: the maintainer still maintains small
tools, and the user sees a single one.
Still, I find this is a pure luxury of people living in a brand new
POSIX world to criticize the existence of these files. When shall we
have `rm == cpmvlnrm --remove', `cp == cpmvlnrm --copy' etc.?
> A lot of small files is meaningful while things are developed. Once
> done, packaging fewer, but bigger files, is often better: just more
> manageable. I would hate to see regexp.[ch] or malloc.[ch] split up
> in a lot of smaller files, probably installed as libraries into
> there own directories, for every package using them.
As long as it doesn't imply some more work to someone I'm fine with
it. Also, there is a huge difference (to me) with `everything in
missing': here it makes sense to put `regex' stuff inside `regex'
stuff. As long as it is automated and logical, fine.
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 enjoy spending time on putting a nice paper around some present I
will make, but the person to whom I will give it will certainly not
criticize me because there is a lot of small polyester balls to
protect it from the shocks, instead of two polyester pieces that match
exactly the form of the object they protect. She cares about the
present, not the box.
> I'm not very comfortable with the current `intl/' and `m4/'
> everywhere, say.
I don't know what you are thinking about `m4', but I see no difference
between an .m4 file and a .c, so as an Open Source developer, I do
expect to receive manageable `.m4' in the packages, not a big
acincludes.m4 as in the old days.
Akim
PS/ Back to the point: I agree `mkdir -p', `install' belong to
`missing', but let's make sure we are not building something which
will become hard to maintain.
