On Wed, Jun 06, 2007 at 10:58:33PM +0200, Axel Thimm wrote:
On Wed, Jun 06, 2007 at 10:26:04PM +0200, Patrice Dumas wrote:
> But I personally find that not that hard to review the changes in
> configure, especially when one get used to.
Look at the size difference of configure.ac and configure. For example
xlibs/Render:
81252 configure
1513 configure.ac
So one each configure.ac line you have 53 configure lines. You're used
to review that these 53 lines really reflect the cahncges in the
master? W/o running autotools youirself to verify this?
I try to do both.
If you do so w/o autotools' aid, then you're a masochist. ;)
Maybe... I don't say that I read all the details, though.
If you use autotools, then why not use them in the sepcfile and have
a
manual step to perform? Manual steps either slow down the process or
are easily skipped and not done at all ...
Because the generated files changes should be reviewed, and by freezing
that there won't be new changes with new autotools.
> > And note, that AM_MAINTAINER_MODE defaults to
--enable-maintainers if
> > not used!!! Which means that 99% of all projects already "abuse"
this
> > if they want to or not.
>
> I disagree. I don't think this feature is for released packages, but it
> is to be used between releases only. Of course I don't want to force
> anybody ;-).
Please read the docs. Autotools and even the author of the
AM_MAINTAINER_MODE recommend to *not* turn off maintainer rules for
very good reasons. These reasons apply here as well. This has nothing
to do with released packages or released software whatsoever.
The reason is
"change to sources files can have no effect on generated files and this
can be very confusing when unnoticed. "
So, yes I am all for having AM_MAINTAINER_MODE set, but it should be
used only to notice that something was modified such that the maintainer
understand what is happening and fix the timestamps and verify what
changed.
> To verify the patch it is better to have a recipe to recreate
it, sure,
> (it could be in comments in the spec file for example) but to review it,
> the diff of the generated file may be enough.
If you need a recipe, then automate it.
But by doing that you also generate a new output file.
> But maybe there was also some humor, here...
Sure, but a lot of truth as well. The general rule is that when there
are build chains, only touch the highest master, not intermediate
files.
Indeed in general it is better, but here it is not exactly the same
because the generated files have a double role.
A more comparable analogon: You wouldn't patch a LaTeX generated
(uncompressed) pdf file if you would just like to fix a typo.
Sure, but in the case of the autotools generated files those files
may have non-trivial consequences.
Anyway let's agree on disagreeing, I really just wanted to add my
2¢
and now the meter is already at 2€. ;)
No problem, I am not sure that we disagree that much, we should look
at particular reviews to know for sure.
--
Pat