[PATCH v2 2/2] Makefile: Only build dtc if needed

[Tom Rini]

On Mon, Apr 27, 2020 at 04:10:06PM -0700, Vagrant Cascadian wrote:
> On 2020-04-27, Simon Glass wrote:
> > On Sun, 26 Apr 2020 at 18:58, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> Am April 27, 2020 12:29:29 AM UTC schrieb Simon Glass <sjg at chromium.org>:
> >> >At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined.
> >> >This
> >> >is wasteful when the system already has a suitable version available.
> >> >
> >> >Update the Makefile logic to build dtc only if the version available is
> >> >too old.
> >> >
> >> >This saves about 2.5 seconds of elapsed time on a clean build for me.
> >> >
> >> >- Add a patch to bring back the dtc-version.sh script
> >> >- Update the check to make sure libfdt is available if needed
> >>
> >> U -Boot has been set up to create reproducible builds. With this
> >> patch dtc will have to be made a build dependency to provide
> >> reproducibility. Cf. https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility
> >>
> >> This may require changes in the packaging of U-Boot in Linux
> >> distributions. Nothing to stop this patch, just something to keep in
> >> mind.
> >>
> >> You presume that future versions of dtc will always be backward
> >> compatible with U-Boot. Ok, we do the same for other tools like gcc
> >> too (with surprises at each new major release).
> 
> In general when packaging for Debian, the preference is to not use
> embedded code copies if at all possible. This does require paying
> attention to backwards and forwards compatibility issues a bit.
> 
> A simple example: The security team in Debian generally likes to fix a
> problem in a single source package, rather than an arbitrary number of
> source packages that happen to share some embedded copy of the code from
> who knows when...
> 
> So at least from my perspective, I'd be happy to use the Debian packaged
> dtc (a.k.a. device-tree-compiler), rather than the one embedded in
> u-boot sources.
> 
> Silently switching to the embedded copy sounds a little scary; I would
> prefer for that to be explicit... a build flag to specify one way or the
> other and failing is better that being too clever about autodetecting.
> 
> 
> > Should we disable this check (and always build dtc) when doing a
> > repeatable build? Is that SOURCE_DATE_EPOCH?
> 
> And with my Reproducible Builds hat on, builds would ideally *always* be
> reproducible, given the same sources and toolchain... several
> distributions and software projects provide information sufficient to
> reproduce the build environment:
> 
>   https://reproducible-builds.org/docs/recording/
> 
> 
> While SOURCE_DATE_EPOCH is definitely one sign that the builder is
> explicitly attempting to be reproducible; It's a bit of a kludge to try
> and be more reproducible just because SOURCE_DATE_EPOCH is
> set. SOURCE_DATE_EPOCH should really only affect the behavior of date or
> time related things; even better would be to not embded time related

This is probably one of those cases where we should just continue to act
like the linux kernel and always use and build our own copy of dtc.
Then, when someone convinces the kernel folks to change their ways, we
can adopt that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200428/f0de366f/attachment.sig>