Re: Best practice for cleaning autotools-generated files?
* Neil Williams <codehelp@debian.org> schrieb:
> ./autogen.sh does not clean anything.
Clarification: with "clean state" I meant a state of the tree
where all the generated files (from autotools+friends) have been
reliably regenerated afresh (no leftovers from previous runs).
Removing temporary files from different stages (eg. configure or
make run) is a completely different issue.
> > 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.
Requires that you can really pass all required options *and*
environment variables reliably. I've seen packages where this
wasn't the case.
And requires the distro packaging system to pass the configure
flags twice (to autogen.sh and configure), yet another piece
of additional complexity.
> > 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.
At least, for autoconf packages, which follow the rules I've written
down here:
http://www.metux.de/index.php/de/component/content/article/1-software-entwicklung/57-rules-for-distro-friendly-packages.html
that would be the case.
Actually, once I fixed packages to this, the individual distro
builder pkg configuration is reduced to nothing more than the
package name, list of available features and their enable/disable
flags, and the individual target config for the package just
tells the version and selected features. That's it.
(see attached files)
> 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
That's not necessary. Having a project, where people like distro
package maintainers come together (at least for a bunch of packages
and growing it later) and maintain stabelized and distro-friendly
downstream branches. (oh, that's what OSS-QM is meant for ;-o)
> > 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.
Probably not. But why not learning from the other areas of engineering ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Reply to: