[Buildroot] [PATCH 2/2] core/instrumentation: shave minutes off the build time

Peter Korsgaard peter at korsgaard.com
Sun Mar 18 16:33:45 UTC 2018


>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:

Hi,

 >> - It doesn't work for packages using rsync to install,
 >> E.G. skeleton-init-common as rsync also sets the mtime to match the
 >> source files

 > We could maybe tell rsycn not to do that, then?

Yes, possibly.

 >> - It breaks for <pkg>-reinstall

 > Well, we can't guarantee anything except with a clean build from scratch
 > anyway.

True. We could potentionally do a touch on the stamp file before running
find, but it is somewhat icky.

 >> I don't think either of those are really big issues compared to the huge
 >> slowdown, but it is worth noticing.

 > Well, the -reinstall was already not working correctly, because the list
 > pf files before/after would be alsmost the same, and the md5-diff would
 > miss all the laready-installed files for the package.

 > The rsync issue is new, but we can "fix" it in a later patch, then, for
 > those packages like the skeletons, by using the --no-times option for
 > example.

Yes. I guess we cannot use --no-times unconditionally in SYSTEM_RSYNC,
as the mtime shouldn't be touched for source files so OVERRIDE_SRCDIR
doesn't rebuild too much.

 > However, if a third-party package internally uses rsync as its install
 > method, we're screwed. But who would be insane enough to do that? ;-]

And even so, the breakage is not so bad.


 > Alternatively, we could use ctime instead of mtime, maybe? Or check
 > both?

ctime would presumably miss modifications to existing files, so that is
no good.

 >> > +define step_pkg_size_inner
 >> > +	cd $(2); \
 >> > +	find . \( -type f -o -type L \) \
 >> > +		-newer $($(PKG)_DIR)/.stamp_built \
 >> > +		-exec printf '$(1),%s\n' {} + \
 >> > +		>> $(BUILD_DIR)/packages-file-list$(3).txt
 >> 
 >> What find version are you using? My fileutils find (and the busybox
 >> applet) use 'l' for symlinks, so I've changed it to that.

 > Doh, the s/L/l/ is still uncomitted here. Dang...

;)

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list