On 10/16/2012 03:38 PM, Andrew W. Nosenko wrote: > Excuse, may be it's too late to party, but... What is the reason to > to invent yet another macro name? Anyway in the most packages there > will be one and the only one line: > AC_CONFIG_MACRO_DIR([m4]) > And even when the many dirs are need, they will be written one by one > in the theirs own macro call: > AC_CONFIG_MACRO_DIR([m4]) > AC_CONFIG_MACRO_DIR([sub/m4]) > AC_CONFIG_MACRO_DIR([pack/m4]) > (The reasons for such stacking is the same as the reasons for lineup > an arguments in a function call with a number of parameters in the > C-like languages -- aesthetics and ability to easy comment out some of > them. The later becomes even more important in languages with the > only one style of comment -- from comment-char to the end-of-line, > like autoconf language.)
The problem is that existing tools (here's looking at you libtool) are inconsistent if you HAPPEN to use AC_CONFIG_MACRO_DIR - some use the first directory, others use the last, and some crash altogether. Back-compat requires that we have a new macro, so that new tools that agree on a common sane semantics use the new name, and where the new name calls AC_CONFIG_MACRO_DIR() exactly once, on the first directory, if AC_CONFIG_MACRO_DIR had not already been used, for best interoperability with old tools. I haven't looked closely at these patches, so I still may end up tweaking the design a bit, but I appreciate Stefano stepping up to fill in a gap from my apparent lack of time at writing a patch that we first discussed that I should attempt more than a month ago. > > Therefore, a question raises: why to invent the new macro name? > Please note, I don't say about implementation. I say about name. If > someone whant to write (or generate, which is more probable) a number > of dirs in the one macro call -- no problems: > AC_CONFIG_MACRO_DIR([m4], [sub/m4], [pack/m4]) > or how it intended to be written, but in wast majority of cases I > expect the name in singular form to be more appropriate. Just change > it's implementation, but left the name as is. Allowing multiple dirs > where only one was allowed is backward compatible. > As a bonus: No needs in playing the game with "this macro is obsolete, > but we don't say you that evenn with -Wobsolete for backward > compatibility". I think we _can't_ mark the old macro obsolete, but at the same time, we must document that the old macro may appear _at most once_, and _prior to any use of the new macro_. > If te plural form (AC_CONFIG_MACRO_DIRS) is needed for some very heavy > reason, then it may me made just an alias to the AC_CONFIG_MACRO_DIR. Using just the m4 perspective, yes, the macros are aliases (they both do nothing). But from the autoconf --trace perspective, having two macros matters, because not all tools used --trace (older libtool was using sed, rather poorly), and we don't want to break interoperability with old tools, all while still allowing new tools (automake 1.13) to take advantage of the multiple directories. -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
