[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 16/12/2021 15:15, Jan Beulich wrote:
> On 16.12.2021 15:58, Andrew Cooper wrote:
>> On 16/12/2021 14:00, Jan Beulich wrote:
>>> On 16.12.2021 10:20, Andrew Cooper wrote:
>>>> 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".
>> all_sources is used exclusively for "tags" purposes; the
>> TAGS/tags/gtags/cscope targets.
>>
>> Personally, I'd prefer there to not be symlinks in the first place.  The
>> EFI logic is unnecessarily complicated to navigate.
>>
>> But the reality is that inter-xen/ symlinks for source files are also a
>> duplication as far as these `find` runes are concerned.
> DYM intra-xen/ symlinks? Else I'm afraid I'm not following.

I do, yes.  I'll find some more coffee.

>
>> Apparently tags et al will follow symlinks, while there's no obviously
>> help online about cscope, other than "resolve your symlinks first".
>>
>> In either case, you don't want to end up with both the regular path, and
>> the symlink, ending up in the file list.
>>
>>
>> I don't anticipate the usecase for all_source changing, nor the way we
>> symlink things, so I think sticking with `-type f` is the appropriate
>> action.
> Well, as said - I disagree, but as long as only targets I don't care
> about are affected, I guess I'll let you do what you want done.

Thanks.

>
>> Furthermore, you really don't want a directory (e.g. include/foo.d )
>> getting into the file list either.
> I certainly agree with you here.

Reading back, I actually meant foo.h/ as a dir, but the intent wasn't lost.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.