Re: [PATCH kvm-unit-tests] cscope: fix database generation

[Bandan Das <bsd@redhat.com>]

Andrew Jones <drjones@redhat.com> writes:

> On Tue, Apr 19, 2016 at 03:44:50PM -0400, Bandan Das wrote:
>> Radim Krčmář <rkrcmar@redhat.com> writes:
>> 
>> > 2016-04-19 14:58-0400, Bandan Das:
>> >> Radim Krčmář <rkrcmar@redhat.com> writes:
>> >>> 2016-04-19 13:08-0400, Bandan Das:
>> >>>> Andrew Jones <drjones@redhat.com> writes:
>> >>>>> On Mon, Apr 18, 2016 at 07:04:55PM -0400, Bandan Das wrote:
>> >>>>>> 
>> >>>>>> The cscope.files that we generate doesn't include all
>> >>>>>> source files that are potentially interesting. We should
>> >>>>>> include all $(ARCH)es  and not the just the one configure
>> >>>>>> finds. Moreover, $(ARCH) expands to x86_64 which is not the
>> >>>>>> correct path for x86 sources. Generate cscope.files by searching
>> >>>>>> for all files starting from root.
>> >>>>>
>> >>>>> No thanks :-) I'd rather not get hits for x86 and powerpc when
>> >>>> 
>> >>>> I don't think that's a good idea. Just because you don't like to
>> >>>> see x86 bits when jumping around in arm code doesn't mean you should
>> >>>> hide all references to a given function. And if the arm code is
>> >>>> segregated enough that there are no common functions, you won't
>> >>>> see them anyway. 
>> >>>> [...]                                               But please let's
>> >>>> not make it difficult to write arm/powerpc tests just because someone's on
>> >>>> x86 :)
>
> How does it make it more difficult to write arm/powerpc tests on x86?
> I do it all the time. Of course you need to run ./configure --arch=<ARCH>
> first, but you need to do that to compile anyway.
>
>> >>>
>> >>> In the kernel, environment can override configuration, so you'd do
>> >>>
>> >>>   % ARCH=arm make cscope
>> >>>
>> >>> and it doesn't matter what arch is being compiled.  I think this would
>> >>> be a better solution for kvm-unit-tests too.
>
> This is what kvm-unit-tests does, except it takes ARCH from config.mak,
> instead of making you specify it, and there is no 'everything' option,
> default or otherwise right now.
>
>> >>>
>> >>> I agree with Drew that other arches would mostly clutter searches if
>> >>> they were included by default, but we can also add a rule in case
>> >> 
>> >> Since you mentioned the kernel, it looks like both the kernel/qemu
>> >> include all by default which makes sense to me.
>> >
>> > qemu does, kernel doesn't (e.g. search for sys_sigreturn).
>> 
>> Not exactly, arch specific(arch/*) files are excluded but there are
>> others such as sound/* include/* that are not all x86 specific. The
>> arch segregation is helpful since there would be functions with similar
>> names (and similar functionality). That's not the case for every file
>> in x86/ and arm/ of kvm-unit-tests.
>
> kvm-unit-tests' cscope find collects all common files and all arch
> specific files, just as you've described about the kernel. Please give
> an example of where you couldn't find something you needed with this
> find, so that I know what the problem is. Also, if there is a problem,

Sorry, you are right. Looks like I was looking at stale files (iotable.c/h)
which don't exist anymore. So, I think the current setup works for me
too since I mostly work on x86. For other times, when I do have to certain
things in other arches, I will just run cscope by hand.

> we can likely extend the find just a bit, rather than changing it to a
> wholesale search.
>
>> 
...
>> 
>> Yes, the option is definitely nice but making it the default, not so much.
>
> As should be clear by now, IMHO, the default is not only nice, but correct.
> Feel free to add a cscope-all target though.

Yeah, I can live with this too. IMHO, the default is a matter of preference, there's
no question of correctness.

>> 
>> > (I don't care about the default much, `ARCH=$sth make cscope` is easy
>> >  to type if the default included all.)
>
> I can live with that too, but I do care about defaults, and defaults
> should target the common cases. I haven't yet seen enough justification
> as to why seeing everything (whether you want to or not) is the best
> common case for kvm-unit-tests' cscope generation.

Me neither, I am not convinced yet how including all files obstructs your workflow
but I am certain living with the defaults won't obstruct mine.

> Thanks,
> drew