[dpdk-dev] [PATCH v4 0/6] Reproducible build

Luca Boccassi luca.boccassi at gmail.com
Fri Aug 11 14:43:05 CEST 2017


On Wed, 2017-06-28 at 17:04 +0100, Bruce Richardson wrote:
> On Wed, Jun 28, 2017 at 08:57:33AM -0700, Stephen Hemminger wrote:
> > On Wed, 28 Jun 2017 14:56:56 +0100
> > <lboccass at brocade.com> wrote:
> > 
> > > From: Luca Boccassi <luca.boccassi at gmail.com>
> > > 
> > > In the past couple of years a concerted effort among almost all
> > > Linux
> > > distros has been striving toward achieving reproducible builds.
> > > [1]
> > > This involves changes to the toolchain, new tools and CI systems.
> > > [2]
> > > 
> > > v1 fixed the documentation, examples and linker script
> > > generation.
> > > v2 fixes all problems, which were caused by unstable order of
> > > headers
> > > inclusion, source files listing and object file listing when
> > > passing
> > > them to the compiler.
> > > DPDK's build, at least with the default configuration, is fully
> > > reproducible with this patch series as tested by the Reproducible
> > > Builds developers experimental toolchain. [3]
> > > 
> > > v3 restores the first patch, which was eaten by git send-email.
> > > 
> > > v4 drops the patch that reorders rebuilds, and adds a patch to
> > > make
> > > the inclusion of headers deterministic with regards to GCC
> > > embedding
> > > the full file path when expading __FILE__ and when writing the
> > > directory listing in the DWARF objects.
> > > It also drops the first 2 patches which have already been merged.
> > > 
> > > [1] https://reproducible-builds.org/
> > > [2] https://reproducible-builds.org/tools/
> > > [3] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolch
> > > ain#Us
> > 
> > Looks good.
> > 
> > Looking ahead, how does this work with the proposed new build
> > system?
> > Is there an automated way to check new submissions so that new
> > features
> > don't undo this.
> > 
> > 
> > Acked-by: Stephen Hemminger <stephen at networkplumber.org>
> 
> http://mesonbuild.com/Reproducible-builds.html
> 
> I'd hope if we switch build system, this shouldn't be a problem. It's
> definitely something to watch out for.
> 
> /Bruce

The one issue to look for, with the current build system, is the CFLAGS
include path order (the last patch) in the makefiles under lib/

The pattern seems to be always the same, would it be possible &
acceptable to add a check in checkpatch?

bad:
CFLAGS += -I$(SRCDIR)

good:
CFLAGS := -I$(SRCDIR) $(CFLAGS)

-- 
Kind regards,
Luca Boccassi


More information about the dev mailing list