On Sat, 7 May 2011 16:51:01 +0200
Enrico Weigelt <weigelt@metux.de> wrote:
> * Neil Williams <codehelp@debian.org> schrieb:
>
> > Nonsense. It is not the job of ./autogen.sh to revert to the VCS state
>
> It is it's job to produce a clean state where *all* generated
> files have been regenerated and the next stage (configure)
> can start from here, w/o any manual intervention or workarounds.
s/clean//
./autogen.sh does not clean anything. It may refresh stuff but it's not
about cleaning things. It's not the job of ./autogen.sh to convert a
semi-built broken setup back to the original VCS state. It simply
regenerates the autotools stuff and provides the ./configure script.
Any ./autogen.sh script which deletes .o files or messes with existing
content in .libs/ directories is RC buggy IMHO. Fair enough if those
are changed when the next 'make' is issued but that's the point, it's
up to $(MAKE), not ./autogen.sh.
> > and there's no harm in ./autogen.sh calling configure with whatever
>
> It *is*, as soon as this cannot run through without special
> flags (eg. if some features have to be switched off, etc).
The options are just passed on unchanged. No problem with that. Can
still call ./configure directly. Maybe it wastes a little bit of time
but if you're cross-building, you're using a really fast machine so
this is hardly of concern.
> > arguments are passed to ./autogen.sh - as long as those options have
> > the same effect when passed to ./configure for subsequent runs during
> > development.
>
> Adds additional complexity to add proper parameters here, for each
> individual package. (and, of course, find out all this first).
>
> This way, you add unnecessary burden to all the maintainers of all
> the distros out there (that might be interested in your package).
and all the other build systems out there are suddenly compatible
across all packages?? Dream on.
> > There is no technical reason for any of these suggestions,
>
> Actually, there is. (okay, maybe more an organisatoric reason).
That's not technical and there is no one organisation which bridges
all of the various upstream teams. If you want to change things, you
must persuade each team to adopt your preferences and you have
singularly failed to convince me - because these ARE preferences, not
best practice.
> Exactly the same reason why things like AC plugs, voltages and
> frequencies are standardized.
Not true. Those things MUST work together in every permutation within a
specific jurisdiction or people can die. Debian and autotools are
nowhere near that level of importance.
(My previous field {for >20yrs} was medical, so don't go assuming I'm
unaware of the risks of non-standard electrical services. I've treated
many patients for the kind of burns which result when things are even
slightly outside the standard.)
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgpqxfivP4eQz.pgp
Description: PGP signature