Alexander Leidinger wrote: > I've just updated autoconf from 2.13 to 2.5x recently. Now configure.in > uses different keywords, so the autoconf versions are not compatible. > I've also seen this incompatibility earlier. So the intend of having > generated files in the CVS is: > - don't force developers to have auto* if they want to help in the > development of LAME (why should I install auto* if I just want to > modify *.[ch]?) > - don't force developers to use particular auto* versions if they don't > have to modify the auto* input files > - make it easier for non-developers to test the recent LAME development > (you just have to learn how to "cvs co" LAME and you can test it) > - provide a consistent development environment (as far as auto* > reaches)
IMHO we're saying the same, but meaning different things. IMHO all the above issues (forcing a particular version of auto* tools) comes up _if_ you supply the generated configure script & other files these tools put into the development directory. Like: depcomp mkisnstalldir install-sh missing ltmain.sh libtool these files actually depend on the version of auto*, libtool, etc. packages you have installed. For example, I spent about 2 hours looking for a configure problem when I realized that the problem is that some of these local libtool files are not in sync with the libtool version on my system. I just had to run: libtoolize --copy --force and all was OK. But now I have these (generated) files marked as modified by CVS: $ cvs -n update -l ? autom4te-2.53.cache cvs server: Updating . M Makefile.in M aclocal.m4 M config.guess M config.h.in M config.sub M configure M configure.in M ltmain.sh U ltconfig where actually on one file is really changed (configure.in). All the rest are generated. As for why would developers need these? Well, they need a range of things: make, gcc, cvs, etc. This is just one of them. It's also worth mentioning, that the Makefile generated by configure will call autoconf & related tools when configure.in or Makefile.am, etc. are changed. Akos _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
