mbox series

[RFC,0/3] add custom logging to DPDK meson runs

Message ID 20201022145944.470054-1-bruce.richardson@intel.com (mailing list archive)
Headers
Series add custom logging to DPDK meson runs |

Message

Bruce Richardson Oct. 22, 2020, 2:59 p.m. UTC
  While the meson.log file in each build directory contains lots of
information, much of it is not of interest to developers, and it can be
hard to see the explicitly messages from the dpdk build files among all
the rest of the content. Futhermore, while at the end of the a
configuration run we print out the list of enable/disabled components,
this is never recorded anywhere for anyone who wants to check that build
configuration later.

This patchset attempts to solve these issues by supporting a
dpdk-meson.log file in each DPDK build folder containing the output from
the DPDK meson.build files - including the final summary information for
later checking.

Bruce Richardson (3):
  build: add a dpdk-specific meson log file
  build: shorten top-level build file
  build: write messages to dpdk build log file

 app/test/meson.build          |  2 +-
 buildtools/meson.build        |  1 +
 buildtools/write-log-entry.py | 23 +++++++++++++++++++++++
 config/arm/meson.build        |  2 ++
 config/meson.build            | 18 ++++++++++++++++++
 config/x86/meson.build        |  2 ++
 drivers/meson.build           |  8 +++++---
 examples/meson.build          |  1 +
 lib/meson.build               |  8 +++++---
 meson.build                   | 31 ++++++++++++-------------------
 10 files changed, 70 insertions(+), 26 deletions(-)
 create mode 100644 buildtools/write-log-entry.py
  

Comments

Bruce Richardson Sept. 15, 2021, 4:23 p.m. UTC | #1
On Thu, Oct 22, 2020 at 03:59:41PM +0100, Bruce Richardson wrote:
> While the meson.log file in each build directory contains lots of
> information, much of it is not of interest to developers, and it can be
> hard to see the explicitly messages from the dpdk build files among all
> the rest of the content. Futhermore, while at the end of the a
> configuration run we print out the list of enable/disabled components,
> this is never recorded anywhere for anyone who wants to check that build
> configuration later.
> 
> This patchset attempts to solve these issues by supporting a
> dpdk-meson.log file in each DPDK build folder containing the output from
> the DPDK meson.build files - including the final summary information for
> later checking.
> 
> Bruce Richardson (3):
>   build: add a dpdk-specific meson log file
>   build: shorten top-level build file
>   build: write messages to dpdk build log file
>
Ping on this old RFC set.

From lack of interest, I'd suggest we drop this set from patchwork as
"Rejected", but if others do thing it's worth pursuing I can investigate
doing a v2, to update to latest codebase.

/Bruce
  
Bruce Richardson Sept. 17, 2021, 1:36 p.m. UTC | #2
On Wed, Sep 15, 2021 at 05:23:24PM +0100, Bruce Richardson wrote:
> On Thu, Oct 22, 2020 at 03:59:41PM +0100, Bruce Richardson wrote:
> > While the meson.log file in each build directory contains lots of
> > information, much of it is not of interest to developers, and it can be
> > hard to see the explicitly messages from the dpdk build files among all
> > the rest of the content. Futhermore, while at the end of the a
> > configuration run we print out the list of enable/disabled components,
> > this is never recorded anywhere for anyone who wants to check that build
> > configuration later.
> > 
> > This patchset attempts to solve these issues by supporting a
> > dpdk-meson.log file in each DPDK build folder containing the output from
> > the DPDK meson.build files - including the final summary information for
> > later checking.
> > 
> > Bruce Richardson (3):
> >   build: add a dpdk-specific meson log file
> >   build: shorten top-level build file
> >   build: write messages to dpdk build log file
> >
> Ping on this old RFC set.
> 
> From lack of interest, I'd suggest we drop this set from patchwork as
> "Rejected", but if others do thing it's worth pursuing I can investigate
> doing a v2, to update to latest codebase.
> 
No further feedback received. Marking as rejected to avoid filling up
patchwork.