----- Original Message ----- From: "Christopher Faylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>
> 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 I disagree with this. It only eliminates that need on projects that have static Makefile.am and configure.in's. I find that active projects, almost invariably add files, with the few exceptions being things like w32api that have tightly set limits from elsewhere. > 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. We simply need a version that will run with automake 1.5 or greater. That is, any developer building setup needs autoconf 2.13 or better (I've put 2.53 in the configure.in's because of the devel scripts on cygwin. I intend to do something about that when I have some spare time to fiddle with specifying which version runs). And automake 1.5 or better. And any libtool that will build static libs. > to build them. It's simple to do that on cygwin if you have automake and > autoconf installed but it's not intuitively obvious. Which is where a 'build-depends:' for setup.exe comes in. Click for the source, get the support tools. > 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) I can see that. What I can do is make a copy of libgetopt++ into the setup directory, rather than referencing the module. I was hesistant about doing that, because that then makes me have to syncronise the two locations, which is also a pain. > 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. Neither do I. I'll wait for Michael, Gary, Pavel and co to chime in. They are the current non-Robert contributors, and it's *their* life I want to make (as well as mine). Rob
