> I disagree that splitting it into several small files is `best' > practise though. If you have only a few macros as we do, having > them in one spot is better than putting some odd 14 files in m4/ > for each macro or something equally silly.
My experience is that having many macros in acinclude.m4 makes it more difficult to diff and update the macro from its upstream source, leading to neglected updates of the code. For example, Inetutils acinclude.m4 contains an old version of the jm_INCLUDED_REGEX macro (serial 12) compared to the regexp.m4 in gnulib (serial 46). If we are using a old version of some macro, then we should change so that we use the new one from gnulib (I'll update it). Most of our macros are very special for our needs though. The thing with seperate files is also that CVS handles moves, renames, and deletion poorly. :-) Come to think of it, perhaps it would be easier to make a gnulib module out of autobuild.m4... That would solve the update problem. Yes, I'll suggest that on the gnulib list. That is a good idea. Thanks. _______________________________________________ bug-inetutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-inetutils
