>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>> 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!
Ralf> *You*, being an advanced auto* developer don't care, but the
Ralf> first time installer of a package will!
Sorry, I should have sprinkled my answer with smileys :) Of course I'm
exaggerating, I do want to keep these files. I was trying to
emphasize ``one task, one file''. I don't want a big STUFF file, I
don't want a big `missing' file. I agree `mkinstalldirs' and
`install-sh' are typically things that should get into `missing', I
agree there are others to come, but I think we should look for a
solution a la shtool which makes it possible to have a modular
`missing'. I fear the road of a hand written fully featured
`missing', that's my point.
More exactly my point was that the ease of maintenance is more
important than a short `ls'. If people want a short `ls', let them
use AC_CONFIG_AUX_DIR!
>> We shouldn't distribute the Makefile.am and configure.in too, there
>> are useless for the installer, and waste bandwidth.
Ralf> I disagree, they are not useless for the installer.
Again, I was pushing the argument to its extreme to denunciate it, I
don't subscribe to what I was saying. Sorry for being unclear.
Ralf> In addition, keeping them as separate files keeps them readable
Ralf> and eases catching differences to the default files.
Aha! You just had the reaction I was hoping to create :)
Ralf> I don't see that a single tool "eases our lives" in
Ralf> general. There are cases where merging the scripts into missing
Ralf> can ease live, but there also are cases where it doesn't.
Yep, that's what I meant.
Ralf> And I have to agree, there is plenty of room for improvement
Ralf> wrt. aclocal-include files in autoconf and automake
Ralf> (eg. ACLOCAL_AMFLAGS vs gnome's aclocal-include.m4)
I didn't mean there is no room for improvement, I was trying to say
that integrating all the m4 files into a single one is not an answer
to me. I tried to emphasize that I don't know what François meant,
and I answered to a question that was not made. I stressed that point
because it belongs to the same spirit: integrating is a good thing as
long as it doesn't diminishes the comfort of a user who decides to
change the package. The package we deliver should be the package we
work on, not something different made to be more beautiful, but less
`maintainer'.
>> 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.
Ralf> Just for completeness: I do not agree, unless autoconf/automake
Ralf> replacements for mkdir or install are fully call compatible to
Ralf> the programs they try to replace/fake.
I agree that `mkdir -p' belong to the spirit of `missing', but I
certainly have no problems with `mkinstalldirs', so I subscribe to
your opinion. They don't pollute my package because theu are in
AC_CONFIG_AUX_DIR, and they don't pollute the maintenance, because
they are small and singled-task tools.
Akim
