On 14.05.21 13:52, Robert P. J. Day wrote:
On Fri, 14 May 2021, Konrad Weihmann wrote:
On 14.05.21 13:16, Robert P. J. Day wrote:
pretty sure i know the answer to this one, but was asked the
other day and wanted to make sure. in order to speed up the normal
OE build, someone suggested bypassing the creation of packages
that weren't going to be relevant, such as -dev, -doc and so on --
the idea was that that could make a significant difference in
build time.
I pretty much doubt it will speed up anything. If for instance the
-dev package will be removed from PACKAGES it is very likely that
the files of that package will end up in the base package ${PN},
which results in larger target packages that need to be installed
(and potentially further RDEPENDS)
Furthermore this will break DEPENDS for recipes that do rely on the
-dev package - so chances are high that this will break (or
magically change) something further down the line.
One thing that you can do to speed up the build process in terms of
packaging time is to delete any **really** not needed files in a
do_install_append, if no proper configuration option (cmake flag,
make flag, PACKAGECONFIG) does exist which prevents the creation of
these files in the first place.
I would recommend not to mess with the packaging defaults for
reasons such as speeding things up - as this is IMHO addressing the
issue at the wrong end - just make sure the files in <workdir>/image
won't get created
that's the general idea i was trying to get across (so let's confirm
that i was speaking accurately). i suggested that the majority of time
spent in processing a recipe was doing all the fetching and unpacking
and patching and (mostly) compiling, the end result of which was to
populate that recipe's WORKDIR/image directory, at which time the
packaging step took over. so unless one wanted to dangerously mangle
the package definitions, if it ended up in ${D}, it was going to get
packaged, correct?
yes... *but* what the packaging does it to loop over PACKAGES and for
each item pick up the corresponding FILES_<pkg-name> var and "move" (I
think it's actually a copy, but that's just details) all matching files
from image to packages-split.
If files ending up in image that don't match *any* of the
FILES-glob-pattern one would get a QA error.
so unless one wanted to go back and mess with the recipe's build
configuration to, perhaps, not generate some artifacts, those packages
were going to be built, whether they were subsequently installed or
not. so short of mangling each recipe file to change its
configuration, just leave it alone as the payoff just isn't worth it.
sound about right?
yes - the results of trimming down the input to /image will much more
have a positive impact.
AFAIK packaging speed is directly linked to the number of files in
/image (worst example I've seen is a ruby package containing 250k+
files, which takes round about 20min to package on my machine) -
concluding from that, reduction of the number of files in /image is will
do the trick
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151759):
https://lists.openembedded.org/g/openembedded-core/message/151759
Mute This Topic: https://lists.openembedded.org/mt/82821703/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
