Re: [RFC PATCH 1/4] xen/Makefile: add analysis-coverity and analysis-eclair

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Nov 14, 2022 at 12:30:39PM +0000, Luca Fancellu wrote:
> The cppcheck workflow instead is:
> 
> 1) call analysis-parse-tags-cppcheck
> 2) generate cppcheck suppression list
> 3) build Xen (and run cppcheck on built source files)
> 4) collect and generate report
> 5) call analysis-clean
> 
> So let’s think about detaching the build stage from the previous stages, I 
> think it is not very convenient
> for the user, as during cppcheck analysis we build 
> $(objtree)/include/generated/compiler-def.h, we build 
> $(objtree)/suppression-list.txt, so the user needs to build Xen where those 
> files are created
> (in-tree or out-of-tree) otherwise the analysis won’t work and that’s the 
> first user requirement (stage #3).
> 
> The most critical input to cppcheck is Xen’s $(CC), it comes from the build 
> system in this serie, the user would
> need to pass the correct one to cppcheck wrapper, together with cppcheck 
> flags, and pass to Xen build stage #3
> the wrapper as CC, second user requirement.

You could add something like that to Makefile:
    export-variables:
        @echo "CC='$(CC)'"

And if "the user" is a shell script, it could easily figure out what $CC
is, without having to duplicate the Makefile's logic for it.

> After the analysis, the user needs to run some scripts to put together the 
> cppcheck report fragments
> after its analysis, this step requires also the knowledge of were Xen is 
> built, in-tree or out-of-tree, so
> here the third user requirement (similar to the first one, but the stage is 
> #4).

Don't support out-of-tree, that would make things easier. I don't see
how that would work anyway with the needed temporary changes to the
source code.

> In the end, we can see the user would not be able to call individually the 
> targets if it is not mastering
> the system, it’s too complex to have something working, we could create a 
> script to handle these requirements,
> but it would be complex as it would do the job of the make system, plus it 
> needs to forward additional make arguments
> to it as well (CROSS_COMPILE, XEN_TARGET_ARCH, in-tree or Out-of-tree build, 
> ... for example).

Well, instead of running `make X XEN_TARGET_ARCH=x86`, a script would be
run as `./script XEN_TARGET_ARCH=x86`, so not much change.
Then the script can easily run `make "$@"`.

Cheers,

-- 
Anthony PERARD