Re: [PATCH v2] automation: Add container and build jobs to run cppcheck analysis

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 14 Feb 2023, Andrew Cooper wrote:
> On 14/02/2023 3:39 pm, Michal Orzel wrote:
> > diff --git a/automation/build/debian/unstable-cppcheck.dockerfile 
> > b/automation/build/debian/unstable-cppcheck.dockerfile
> > new file mode 100644
> > index 000000000000..54b99f87dfec
> > --- /dev/null
> > +++ b/automation/build/debian/unstable-cppcheck.dockerfile
> > @@ -0,0 +1,37 @@
> > +FROM arm64v8/debian:unstable
> > +LABEL maintainer.name="The Xen Project" \
> > +      maintainer.email="xen-devel@xxxxxxxxxxxxxxxxxxxx"
> > +
> > +ENV DEBIAN_FRONTEND=noninteractive
> > +ENV CPPCHECK_VERSION=2.7
> > +ENV USER root
> > +
> > +RUN mkdir /build
> > +WORKDIR /build
> > +
> > +# dependencies for cppcheck and Xen-only build/cross-build
> > +RUN apt-get update && \
> > +    apt-get --quiet --yes install \
> > +        build-essential \
> > +        curl \
> > +        python-is-python3 \
> > +        libpcre3-dev \
> > +        flex \
> > +        bison \
> > +        gcc-arm-linux-gnueabihf \
> > +        gcc-x86-64-linux-gnu
> > +
> > +# cppcheck release build (see cppcheck readme.md)
> > +RUN curl -fsSLO 
> > https://github.com/danmar/cppcheck/archive/"$CPPCHECK_VERSION".tar.gz && \
> > +    tar xvzf "$CPPCHECK_VERSION".tar.gz && \
> > +    cd cppcheck-"$CPPCHECK_VERSION" && \
> > +    make install -j$(nproc) \
> > +        MATCHCOMPILER=yes \
> > +        FILESDIR=/usr/share/cppcheck \
> > +        HAVE_RULES=yes CXXFLAGS="-O2 -DNDEBUG -Wall -Wno-sign-compare 
> > -Wno-unused-function"
> 
> I think you want to be using a mutli-FROM dockerfile here, otherwise
> you're including all the intermediate build artefacts in the final image.
> 
> See debian/buster-gcc-ibt.dockerfile for an example.
> 
> That said, I'm not sure we want to be making custom containers for every
> minor tweak we have on a build environment.  What's wrong with just
> putting CPPCHECK in the normal container?

cppcheck is not large but needs to be built from source (as part of the
Dockerfile). So we thought it would be best to keep it separate from the
regular containers.

I don't foresee another case like cppcheck at the moment.

Also by having it separate it is clearer that this container is
"special".

I think it would be preferable to keep it in its own separate container
but it would be OK either way.