Ronan Waide wrote:
> On January 26, [EMAIL PROTECTED] said:
> > Fair enough. Modifying .cvsignore to include configure seems to have
> > solved the problem. I guess I don't grok CVS well enough to
> > understand the problem but I don't want to cause any pain. I wonder
> > if adding configure to .cvsignore in the repository would be
> > appropriate, though since it's already set up to ignore the other
> > generated files (like Makefile, config.status etc).
> >
>
> Yep, that's right. On the list of things to do, if Didier doesn't beat
> me to it.
For the record, I'm *against* removing the configure script from the
CVS archive. The rule «generated files don't go in CVS» is in general too
strict for many situations.
My arguments are the following:
1/ there are different kinds of «generated files». Makefile's are generated at
build time, and depend on the _user_ environment. They're very likely to be
different from build to build so it is obvious to exclude them from the
archive. `configure', on the contrary, is the same file for _everybody_ so
it makes a lot of sense to have it in the archive. Put it another way, why
would you require every single person to rebuild the _same_ file locally ?
2/ building the `configure' script requires a working autoconf. This is
already a supplementary burden for each CVS user: we shouldn't force them
to have a working autoconf to build BBDB, and I mean it, even for CVS users
that are expected to be willing to leave on the bleeding edge. But there is
worse: «having a working autoconf» is not in general sufficient. You have
to use preferably the same autoconf as the one I'm using. For now (for the
release I mean), I stayed on autoconf 2.3 on purpose. But my plan is also
to move quickly to autoconf 2.50, which is not yet released. As a
consequence, this will impose that *all* of our CVS users move to this
autoconf version, and what's more, the number of erroneous bug reports that
we will receive because of version mismatch is very likely to be important.
We're shooting ourselves in the foot.
3/ the only real argument in favor of excluding configure from CVS is that
this sort of file usually generates more conflicts that common files, and
these conflicts are very difficult to edit by hand. However, the script is
not likely to change very often, and 'rm configure ; cvs update configure'
is not very painful to type, as a conflict resolution mechanism ;-)
That's why I think configure should stay in CVS. That is the case for
many softwares, including XEmacs.
--
/ / _ _ Didier Verna http://www.lrde.epita.fr/~didier
- / / - / / /_/ / EPITA / LRDE mailto:[EMAIL PROTECTED]
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
_______________________________________________
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/
