Oliver Graf <[EMAIL PROTECTED]> wrote: > > Oh, and when submitting patches to configure.in, I'd suggest submitting > > the equivalent patch to configure. Otherwise if someone overlooks the > > regeneration, it appears to not work for no apparent reason. > > Hmmm. I did not do this, cause other projects I'm participiating in do > not keep configure in cvs cause its an autogenerated thing. But I will > try to keep this in mind, if I have to do another configure.in patch > sometimes.
Personally, I'd prefer to *not* see patches to 'configure'. They tend to be huge and pointless, as they can be re-generated from 'configure.in'. The reason that 'configure' is in CVS is that it's easier that way. I've seen projects where the instructions for the snapshots are "run autoconf, then ./configure ...". But if you have a different version of autoconf than they do, it doesn't work. And even if you have the same version of autoconf, they didn't bother to explain which extra magic parameters you need to pass to it, etc. Having 'configure' in CVS means that the developers need to take an extra step, involving ~15 seconds when they make (rare) changes to the configure scripts. NOT having it in CVS means that endless other developers and users will curse your name. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
