Re: [PATCH] xen/build: Fix `make cscope` rune

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.12.2021 10:20, Andrew Cooper wrote:
> There are two problems, both in the all_sources definition.
> 
> First, everything in arch/*/include gets double hits with cscope queries,
> because they end up getting listed twice in cscope.files.
> 
> Drop the first `find` rune of the three, because it's redundant with the third
> rune following c/s 725381a5eab3 ("xen: move include/asm-* to
> arch/*/include/asm").

I'm certainly fine with this part.

> Second, and this way for a long time:
> 
>   $ make cscope
>   ( find arch/x86/include -name '*.h' -print; find include -name '*.h' -print;
>   find xsm arch/x86 common drivers lib test -name '*.[chS]' -print ) >
>   cscope.files
>   cscope -k -b -q
>   cscope: cannot find file arch/x86/efi/efi.h
>   cscope: cannot find file arch/x86/efi/ebmalloc.c
>   cscope: cannot find file arch/x86/efi/compat.c
>   cscope: cannot find file arch/x86/efi/pe.c
>   cscope: cannot find file arch/x86/efi/boot.c
>   cscope: cannot find file arch/x86/efi/runtime.c
> 
> This is caused by these being symlinks to common/efi.  Restrict all find runes
> to `-type f` to skip symlinks, because common/efi/*.c are already listed.

I have reservations here, albeit of theoretical nature as long as only
the csope target is affected (simply because I don't use it): Make
rules should really be independent of a dir entry being a real file or
a symlink. I did run into problems with that already years ago when
the shim was introduced. My arrangements heavily use symlinking, and
any assumption on files being "real" ones will break this. At the very
least symlink checks should be restricted to cover only relative ones;
ideally one would distinguish ones staying within the tree vs ones
reaching to the "outside".

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -468,9 +468,8 @@ arch/$(TARGET_ARCH)/include/asm/asm-offsets.h: 
> asm-offsets.s
>  
>  SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers lib test
>  define all_sources
> -    ( find arch/$(TARGET_ARCH)/include -name '*.h' -print; \
> -      find include -name '*.h' -print; \
> -      find $(SUBDIRS) -name '*.[chS]' -print )
> +    ( find include -type f -name '*.h' -print; \
> +      find $(SUBDIRS) -type f -name '*.[chS]' -print )
>  endef

I further wonder how use of $(TARGET_ARCH) can be correct here. Why
would the enumeration of items here be limited to a particular arch?
When you edit files in the source tree, everything should be covered.
Restriction to a particular arch only makes sense in a build tree.

Jan