[Fuego] dbench no longer builds on any of my boards

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Daniel Sangorrin 
> 
> > -----Original Message-----
> > From: Tim.Bird at sony.com 
> > I should have held off ACK-ing the patches until my test runs completed.
> >
> > That issue you mentioned with  dbench requiring libpopt is a killer.
> 
> Yes, it is  a killer.
> 
> > The previous dbench was building for all of my boards, and this one
> > doesn't build for any of them (OK - that's only 3 toolchains, but still).
> >
> > The default debian-armhf toolchain doesn't include popt.h, nor
> > does the yocto project SDK for aarch64, nor does the default
> > debian x86_64 toolchain.
> 
> For debian toolchains all you need to do is install the libpopt-dev library.
> Note, that I already tell you that  on the error message. We could add that
> library to the Dockerfile and the arm toolchain installer script. However,
> now I am thinking of a different approach. Currently I am fixing the kernel
> build test, and I have added a "dependencies" item to test.yaml. The idea
> is to keep track of the build dependences of each test separately not in
> the Dockerfile where everything is mixed and we have no control.

The profusion developers ran into the same issue, and started working on
it.  Basically, I think the debian packages needed for test building should be
separated from those in the base "Fuego distribution".  We can add
libpopt-dev to the toolchain installer script (I have nothing against that).
But in general this solution doesn't scale.   If we have thousands of tests,
we can't be installing every library in existence.  Each test should indicate
its own build dependencies (as you say), and we should only install the
ones needed for the tests that are installed in the system.
> 
> For Yocto generated SDK, you would need to add the library to your sdk. Or
> easier, add the dbench test to your target filesystem.

The problem with adding dbench to the target system is that this is
not a solution for testing final products.  Final products should not have a bunch
of extra testing binaries on them.  Most consumer products I've worked on
have two configurations: the developer configuration and the production
configuration.  The production configuration usually has all the testing material
stripped out.  This is especially important for low-footprint devices.

> 
> > Is there any way to work around or remove this dependency?
> > Two options come to mind:
> >  - patch the code to use something else
> >  - include the popt code in the test sources, and build it before building
> dbench.
> >
> > Let me know what you think.
> 
> OK, I will work on that.

Which item are you working on?  I was going to take a look at dbench and see
how dependent it is on libpopt.  They just added this recently, so it might
not be that tightly integrated yet.
 -- Tim