On Fri, May 14, 2021 at 5:39 AM Konrad Weihmann <kweihm...@outlook.com> wrote:
>
> 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
This thread seems to have covered the main point already (if you want
to save time by not packaging unwanted files then don't install the
files in the first place).
It's perhaps worth noting one very common case where files are
installed and packaged unnecessarily and that's having the ptest
distro feature enabled even though you don't intend to install any
ptest packages. For most users ptest should be something you enable
selectively when you want to prove the functionality of recipes in
oe-core (e.g. after upgrading to a new OE release or when bringing up
a new machine) and then disable again afterwards.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151989):
https://lists.openembedded.org/g/openembedded-core/message/151989
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]
-=-=-=-=-=-=-=-=-=-=-=-
