Hi, why would someone want to check in derived files like configure and Makefile? Because someone might not have autotools? Why not also checking in objects and libs in case someone might not have a compiler installed?
On Fri, Apr 30, 2010 at 5:57 AM, Trevor Harmon <tre...@vocaro.com> wrote: > For this discussion I think it's important to recognize that > there are two distinct classes: > > 1) People who download a source tarball > 2) People who check out the source from a repository Just for sake of completeness / for the bigger scope I'd like to add: 3) People who use a binary distribution I think this is the biggest group of users. Often they get the bin dist from a package maintainer who in turn works on a src dist, which might be configured specifically and she may have patched and/or extended the src dist. > #1 are the "users" or "end users" who just want to download, > build, and install a stable release. They typically don't care > about getting code from the repository. Yes, I agree, for those the source dist is for and thanks to autoconf it is done in a way that it can be built easily. Of course, you must have installed make, a compiler... The documentation should tell what exactly is needed. > #2 are the "developers" who are testing prereleases, hacking on > the code, contributing patches, etc. This usually requires > checking out the source from the repo. For these people I don't > see any problem with requiring them to install autoconf >= 2.59 > (or whatever) and to run a single command (autoreconf -i) to > bootstrap the build. They most likely have it installed already > anyway! Yes, I completely agree. They have to have installed make, a compiler, autotools... How else should they be able to add a new source file? Also they have to be able to use their own versions of the tools. > I realize there may be some overlap between the two groups -- > for example, "power users" who just want to try out > cutting-edge code I guess most power users do have autotools installed :-) Personally, I dislike to have derived files in version control. It is redundant, not DRY. Also can invite trouble, for example, it could happen that the checked-in configure does not match the configure.ac or so. Are there SCMs that don't support file ignore lists? SVN has its properties stuff, might be a bit clumpsy for non-ant-java-mainline projects to add all the files, but most work is just needed once by one of the developers of the team, so shouldn't be a problem I think :-) To get rid of all the autogen files and to check if the current state is reproducible from VCS a simple way is to simply check it out and build it. If there are no derived file in the repository, all files have to be generated and if anything is missing or wrong, at least make check has a chance to spot it (otherwise, someone may have extended let's say configure.ac, checked in configure but not configure.ac and noone would notice, then second one changes configure.ac and then you wonder why configure suddenly fails or so). oki, Steffen
