Re: [Qemu-devel] [PATCH for-2.8 v1 00/60] Modular build of trace event files

[Fam Zheng <famz@redhat.com>]

On Wed, 08/10 09:24, Daniel P. Berrange wrote:
> On Wed, Aug 10, 2016 at 04:13:10PM +0800, Fam Zheng wrote:
> > On Wed, 08/10 09:06, Daniel P. Berrange wrote:
> > > On Wed, Aug 10, 2016 at 09:41:40AM +0800, Fam Zheng wrote:
> > > > On Tue, 08/09 18:11, Daniel P. Berrange wrote:
> > > > > 
> > > > > Can we get this report to include details of the
> > > > > 
> > > > >   a) the software versions of gcc, binutils, and any -devel packages
> > > > >      we're building against
> > > > > 
> > > > >   b) the exact arguments + env variables used to invoke configure,
> > > > >      not merely its output
> > > > > 
> > > > > so we don't have to go digging into the docker test systemm to
> > > > > try and reverse engineer this info
> > > > 
> > > > The whole point of docker test system is offer a relatively easy reproducer to
> > > > developers, so I'm reluctant to engineer patchew or the test script it runs for
> > > > that.
> > > 
> > > That's just pointlessly creating extra work for the developers reading
> > > these build reports. If you outputted the info I suggest, it can help
> > > developers diagnose the problems more quickly. Even if running the
> > > docker env locally is possible & even easy, it doesn't make it faster
> > > than reading the relevant info from email report in front of you.
> > 
> > I agree with your point, I just don't know how to do a) neatly, except for a
> > vast change to configure.
> 
> Why do you need todo it in configure ?  I was thinking your docker receipe
> that invokes configure could just do it - not least because the commands to
> run to get the data will be different based on which distro you're running
> in the docker image in question.

Then the script needs to be updated to work with different package management
systems (rpm and deb). For now they only call standard Linux commands.  That's
least of the problem, though.

The more tricky question is how the script can tell which packages are relevant
(or, used). I assume the number of packages in a docker image is quite limited
(fedora has 396, ubuntu 574), but dumping the whole list is still noisy
nevertheless. Also, depending on the configure option, a submodule can be used
instead, or a local built library. Not that we have a lot of these now, but
it's a factor of complication.

On the other hand, configure knows when to use pkg-config --modversion, or git
describe, or something else, depending on how and where it discovers the
compiler and -devel libs etc..

Fam