On Mon, Apr 29, 2002 at 10:33:34PM +1000, Robert Collins wrote: >> 8) What's the big deal with adding a few files to the CVS? > >It's a PITA. Diffs get bigger, Changelogs get garbage 'Makefile.in: >Regenerated.' entries. And when developers have different autotool >versions, committing becomes a PITA because you cannot commit the >generated files, or you end up with multiple huge patchs. And I think >that asking every developer to have the *same* autotool versions is a >much bigger ask than asking any CVS user to have *a* autotool version.
It's precisely the autotool version number that is the common reason for checking autogenerated files into CVS. It eliminates the need for other developers to have the same version of the autotools. For instance, if you require version 2.52 of configure.in for libgetopt++ then that means that anyone who is cross-building on linux will need that version. However, this version conflicts with things like gdb, binutils (I think), and gcc. I know how to fix that but, IMO, it presents a barrier to doing simple development. If I just want to make a change to a source file, and could care less about configure or Makefile.in, I still have to figure out how to build them. It's simple to do that on cygwin if you have automake and autoconf installed but it's not intuitively obvious. It also seems inconsistent to me to use one philosophy in setup and another in a library used for setup. (Yes, I do know that libgetopt++ is intended as a general purpose library) Wrt, the "regenerated" messages, I really don't think they're a big deal. Especially, since configure changes are rather rare since so few people want to mess with configure.in or Makefile.am. I'm not going to issue an edict since I don't think it's a big enough deal. I just think that not including configure, Makefile.in, and Makefile are a barrier towards contribution. If you still don't want to include them that's your call. I, personally, don't really want to have a long discussion about the pros and cons. cgf
