Akim Demaille wrote:
>
> >> Akim
> > François
>
> >> Honestly, I see no difference between plenty of small utilities and
> >> one big.
> 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!
*You*, being an advanced auto* developer don't care, but the first
time installer of a package will!
> We shouldn't
> distribute the Makefile.am and configure.in too, there are useless for
> the installer, and waste bandwidth.
I disagree, they are not useless for the installer. There are many
packages which use the default files, but in case they have been
modified, they contain very important information (COPYRIGHT,
ChangeLog, INSTALL).
AFAIK, they are only there to encurrage developers to fill them, but
as you correctly say, many developers don't care.
In addition, keeping them as separate files keeps them readable and
eases catching differences to the default files.
Anyway, what you are saying, from my perspective boils down to
making --foreign the default instead of using --gnu, because
AUTOMAKE_OPTIONS=foreign already prevents automake -a from adding
these files.
>
> 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.
I don't see that a single tool "eases our lives" in general. There
are cases where merging the scripts into missing can ease live, but
there also are cases where it doesn't.
Eg. install-sh is a portable and call-compatible replacement for
bsd-installs on systems which don't have one - It's convienient to
have it and not having to bother with missing --install or similar.
> 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!
Fully agreed.
> > 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.
AFAIU, François is talking about aclocal macro include directories
and how to handle them in packages.
And I have to agree, there is plenty of room for improvement wrt.
aclocal-include files in autoconf and automake (eg. ACLOCAL_AMFLAGS
vs gnome's aclocal-include.m4)
>
> 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.
Just for completeness: I do not agree, unless autoconf/automake
replacements for mkdir or install are fully call compatible to the
programs they try to replace/fake.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
