[Pdbg] [PATCH 2/2] utils: Add script to run make check

[Joel Stanley]

On Mon, 13 Aug 2018 at 17:30, Amitay Isaacs <amitay at ozlabs.org> wrote:
>
> On Mon, 2018-08-13 at 17:11 +0930, Joel Stanley wrote:
> > Hi Amitay,
> >
> > On Mon, 13 Aug 2018 at 16:56, Amitay Isaacs <amitay at ozlabs.org>
> > wrote:
> >
> > > > +docker pull ubuntu:18.04
> > > > +docker build -t ${CONTAINER} - <<< "${Dockerfile}"
> > > > +
> > > > +RUN="docker run --rm=true --user=${USER} -w ${PWD} -v
> > > > ${HOME}:${HOME} -t ${CONTAINER}"
> > > > +
> > > > +${RUN} ./bootstrap.sh
> > > > +${RUN} ./configure
> > > > +${RUN} make clean
> > >
> > > Does travis cache the older image?  Or it's always created from
> > > scratch?  If it's created from scratch, then we don't really need
> > > "make
> > > clean".  If not, we also should add "git clean -x -d -f" before
> > > running
> > > "./bootstrap.sh"
> >
> > Travis doesn't appear to cache the containers. We do cache them on
> > openpower.xyz's Jenkins. When I use them locally, it is cached.
> >
> > We don't want to do a git clean in the script as that might have
> > unexpected results for people using it in their local tree.
> >
> > For our CI (Travis, Jenkins) the workspace will be clean each time,
> > so
> > the make clean is unnecessary. This these files are not just for
> > travis, but is intended for anyone wanting to do a build. Hence the
> > make clean which is useful if the previous build was a cross-compile.
> > Without the clean a user might get this:
> >
> >    CCLD     pdbg
> > /usr/bin/x86_64-linux-gnu-ld: unknown architecture of input file
> > `fake.dtb.o' is incompatible with i386:x86-64 output
> > collect2: error: ld returned 1 exit status
>
> More confusion.  So docker is only for access to cross-compilers?
> I assumed that the build was in a directory in the docker container.
> Didn't realize that it's actually the directory on the host.

We use docker's "mount volume" option to mount the source directory at
the same path as it exists on the host machine. This allows the user
(or CI) to build the tool without necessarily having the tools
installed on their host machine (or the same versions).

I first used this technique when developing a systemd application for
openbmc, when openbmc's libsystemd was newer than the one on my
machine. You can still use your host's editor and what not, but the
build process is isolated.

I find it useful even for small tools without many external
dependencies like pdbg, as it lets me test on a released version of
the distro, and you find out when a new dependency has been added
pretty fast.

Cheers,

Joel