Hi Kohei,
maybe here are a few words in order to explain how release engineering
handles 'configure'. If there are two CWSs with conflicting changes to
'configure' integrated at the same time - and they will conflict if
there are two versions of configure.in or just two different versions of
autoconf - RE will regenerate 'configure' and commit it. We use a pretty
old versions of autconf, I think it 2.59. We like it to always use the
same version of autoconf, because this keeps the diffs small and we are
least able to quick check of the plausibility of configure. Always using
the same version of autoconf is therefore not an absolut must but a
convenience. If 2.59 is no longer good enough please tell us which
version of autoconf is the agreed on best version nowadays.
Heiner
PS: A developer needs not to check in 'configure', there is a standing
agreement that RE will regenerate it during integration. It has happened
that we overlooked it so it never hurts if you commit it, too. A
conflict will not be overlooked by us :-)
Kai Backman wrote:
On 10/4/06, Kohei Yoshida <[EMAIL PROTECTED]> wrote:
OTOH, when I have autoconf autogenerate the 'configure' from the
'configure.in' template, it runs fine. But of course that would
drastically alter the content of 'configure' from that in the
repository, which is of course not good for version control purposes.
Running autoconf and checking in everything is exactly what you should
do. "configure" is not a source file and is only checked into the
repository because of convenience. It is OK if it changes radically,
we are only interested in the changes in "configure.in". Do try to use
a relatively new autoconf, I remember _rene_ having issues with older
versions (?).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
