On 31 Mai, Akos Maroy wrote:
> 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
If you don't touch a generated file, it shouldn't make a difference.
Except someone commits the generated files in the wrong order.
> 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:
[list of files]
> where actually on one file is really changed (configure.in). All the
> rest are generated.
If you change a file, you should know what you are doing (regenerate
files if you have different versions of the used tools).
Most of the developers don't need to touch auto* input files so usually
this isn't an issue.
> 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.
Then don't change theses files if you don't have auto*. :-)
And if a fresh checkout wants to generate such a file, then you've found
a bug which needs to get reported.
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
