Keith M Wesolowski wrote: > I'm not really convinced that any warning or restriction is > sufficient; libtool is so toxic that this project should not be done > at all. Since it appears it's going to be done anyway, adding more > warnings seems preferable where supported by policy. > > What about not documenting libtoolize at all and introducing > /usr/share/libtool/libtoolize --automake as a Consolidation Private > interface (consumed by automake)? Again, I don't think it's enough, > but it might be a step in the right direction.
In practice, libtoolize is sometimes needed (outside of automake's use) when building OSS that has been modified from the released version, eg to replace older-version libtool files in the tarball and ensure the installed libtool version is being used. My general approach in doing libtool is that is it a necessary evil that we should provide for developers working on OSS. We should provide a fully-functional, standard implementation and add appropriate warnings/notices in the manpages, but beyond that, developers use it at their own risk. So, I agree that a minimal manpage for libtoolize should be added, with the same warning and stability note - I will update the case. But, I think hiding commands or printing warnings when the commands are invoked is too much - is seems the latter is normally intended for interfaces that are about to be removed? As for 64-bit libltdl: good question. Any consumers of ltdl I know of only require 32-bit, but if anyone knows of a case where a 64-bit lib would be needed, let me know and I can add that, too. - Dermot
