_sc_search_regexp gives different results between VPATH configurations and non-VPATH configurations. By VPATH configurations, I mean build trees that result from "../foo/configure" as opposed to "./configure".
AIUI, the problem is that the list of files offered to the filter is different in each case. For non-VPATH builds, vc-list-files is run with the option "-C ." For VPATH builds it is run with the option "-C ../foo" or something like that. The result is that the filtering condition is applied to a stream of names which may or may not include a $(srcdir)/ prefix. Let's take sc_readme_link_copying as our example. In a non-VPATH build we get essentially this: $ ./build-aux/vc-list-files -C . | grep -E '^README$' README For a VPATH build however, we get this: $ ../cssc/build-aux/vc-list-files -C ../cssc | grep -E '^README$' In other words, for maintainers who customarily use VPATH, some syntax checks silently do nothing, only to fail later in "distcheck". Changing "^" to "/" doesn't seem to be the right fix in the case of sc_readme_link_copying because we only really want to perform this check on the top-level README, and other files are likely to generate false positives: $ ../cssc/build-aux/vc-list-files -C ../cssc | grep -E '(^|/)README$' ../cssc/README ../cssc/tests/README ../cssc/testutils/README The targets I suspect are affected by this problem include: sc_changelog sc_m4_quote_check (which will omit configure.ac) sc_readme_link_install sc_readme_link_copying It looks to me as if there is an analogous problem with the in_files filter, but fortunately the checks that use it don't assume that ^X will match a top-level file whose name starts with X. VC_LIST_EXCEPT carefully removes the $(srcdir) prefix before filtering with exclude_file_name_regexp--<some suffix> and then re-adds the prefix, but the same does not happen when applying the in_files and in_vc_files filters. Thanks, James.
