Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I see that there are many other uses of "$result" in that file. >> How about using a name that doesn't impinge on the configure.ac >> writer's name space? E.g., s/result/gl_result/g in stdint.m4 > > There are many more shell variables used in macros that don't have a > particular prefix. > > acl.m4 use_acl > csharpcomp.m4 error > eoverflow.m4 have_eoverflow > gc.m4 libgcrypt > gettext.m4 is_woe32dll > host-os.m4 os > intdiv0.m4 value > javacomp.m4 source_version target_version goodcode failcode \ > cfversion > lib-link.m4 with_gnu_ld wl libext shlibext \ > hardcode_libdir_flag_spec hardcode_libdir_separator \ > hardcode_direct hardcode_minus_L enable_rpath \ > use_additional additional_includedir \ > additional_libdir rpathdirs ltrpathdirs \ > names_already_handled names_next_round \ > names_this_round already_handled uppername value \ > found_dir found_la found_so found_a haveit basedir \ > dir alldirs next > lib-prefix.m4 searchpath > ls-mntd-fs.m4 getfsstat_includes > nanosleep.m4 nanosleep_save_libs > perl.m4 candidate_perl_names perl_specified found > po.m4 srcdirpre useit desiredlanguages lang frobbedlang \ > presentlang > ptrdiff_max.m4 result > signalblocking.m4 signals_not_posix > size_max.m4 result > stdint.m4 result
Thanks for identifying those. > 1) Do you think it's worth to change them all? Did you experience a > collision between your variables in configure.ac and one in *.m4? Yes, I have experienced collisions (though none recently). That's why I brought it up. They are far more likely with short and generic names like $found, $result and $dir. Although I wouldn't worry about the long ones, it would be nice to rename them use a prefix, too. > 2) When using such namespaces, moving macros from/to gnulib needs renamings. > Unnecessary diffs. IMHO, the important thing is that there be *some* prefix. Having a mix of e.g., gl_ and gt_ prefixes shouldn't cause trouble.
