> I developed/maintain the configure script for ImageMagick. While the
> total lines in the generated configure script is meaningless, it is
> less than 1/2 of what you report for PHP, and PHP's configure script
> is 4-8X larger than typical configure scripts for other large packages
> (e.g. 4X larger than the configure script for OpenSSH). This seems
> odd to me.
There is lot of redundancy included which might be the reason
for the slow down. I have thought about using shell
functions instead of expanding m4 macros all the time. That
might improve things a bit.
> Having adopted every new Autoconf which has been released, I can
> happily say that as long as you avoid using undocumented Autoconf
> internals, it is not particularly difficult to make the minor
> modifications required to stay current.
PHP's system has been supporting autoconf 2.50 since its
inception. 2.5x is a burden on the developer's though who
improve the build system. The more time an edit/build cycle
takes, the less likely someone will try to make modifications
and/or test them properly.
> I don't believe that the decision by some factions to stick with a
> particular Autoconf software version for the rest of time should be
> allowed to hinder the development of Libtool.
Well, if it is possible for a complex framework as ours to
maintain compatibility, there should be only few reasons why
it cannot work for libtool as well. Of course, whoever
spends their time on libtool development gets to make the
final decision.
- Sascha
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
