Thank you Nicolas for asking this question since I will probably run into
this issue soon if not for this email thread. The answers so far have been
very helpful but I just want to clarify a bit more on why doesn't the
package get rebuilt? From my understanding, Yocto should rerun a task when
the signature of the task changes and since do_install has an override on
mydistro-dev, shouldn't the content and thus the signature of do_install
change when switching distro and so Yocto should rerun it? I have a lot of
tasks with override not just on DISTRO but other things like MACHINE or
custom variables so I want to understand the rebuild mechanism as best I
can.
Best,
Khoi Trinh
On Tue, Jul 12, 2022 at 8:05 AM Mike Looijmans <mike.looijm...@topic.nl>
wrote:
> Quick answer: Don't build multiple distros in one build directory.
>
> You might get away with setting TMPDIR = "tmp-${DISTRO}" to give each
> its own.
>
> But I'd rather advice to set up two separate builds and just point the
> downloads and sstate-cache to the same location. It'll be faster than
> the TMPDIR option.
>
> Or figure out how to put the difference in the IMAGE only. Then you can
> just build both images (in parallel, woot), which is faster, more
> convenient and saves on diskspace.
>
> What I often do is have my-application.bb generate a
> my-application-utils package that only gets installed in the "dev" image
> but not in the production one, which only installs "my-application".
>
> You could also create a "my-application-dev.bb" recipe that includes
> my-application.bb and just changes what it needs to be different.
>
>
>
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
> System Expert
>
>
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
>
> T: +31 (0) 499 33 69 69
> E: mike.looijm...@topicproducts.com
> W: www.topic.nl
>
> Please consider the environment before printing this e-mail
> On 12-07-2022 15:37, Nicolas Jeker via lists.yoctoproject.org wrote:
> > Hi all,
> >
> > I'm currently using an additional layer and image to differentiate
> > between a release and development build (enabling NFS, SSH, root login,
> > etc.). To create a development build, I manually add the layer to
> > bblayers.conf. This works quite well, but feels a bit clumsy to
> > integrate into a CI/CD pipeline.
> >
> > Per these past discussions here [1][2], I'm now trying to migrate to
> > multiple DISTROs, something like "mydistro" and "mydistro-dev".
> >
> > While migrating some of the changes, I discovered that I run into
> > caching(?) issues. I have a recipe for an internal application and want
> > to include additional systemd service files in the development image.
> >
> > What I did was this:
> >
> > Added "application-dbg.service" to recipes-internal/application/files
> >
> > Adapted application.bb recipe:
> >
> > SRC_URI:append:mydistro-dev = " file://application-dbg.service"
> >
> > do_install {
> > # ...snip...
> > # systemd service
> > install -d ${D}${systemd_system_unitdir}
> > install -m 0644 ${WORKDIR}/application.service
> > ${D}${systemd_system_unitdir}
> > }
> >
> > do_install:append:mydistro-dev() {
> > # debug systemd services
> > install -d ${D}${systemd_system_unitdir}
> > install -m 0644 ${WORKDIR}/application-dbg.service
> > ${D}${systemd_system_unitdir}
> > }
> >
> >
> > When I run "DISTRO=mydistro-dev bitbake application" followed by
> > "DISTRO=mydistro bitbake application", the debug service file is still
> > present in the package. This seems to be caused by the "image"
> > directory in the recipe WORKDIR not being cleaned between subsequent
> > do_install runs. Is this expected behaviour? What's the best solution?
> >
> > Kind regards,
> > Nicolas
> >
> > [1]:
> >
> https://lore.kernel.org/yocto/CAH9dsRiArf_9GgQS4hCg5=j_jk6cd3eigaoiqd788+isltu...@mail.gmail.com/
> > [2]:
> >
> https://lore.kernel.org/yocto/vi1pr0602mb3549f83ac93a53785de48677d3...@vi1pr0602mb3549.eurprd06.prod.outlook.com/
> >
> >
> >
>
> --
> Mike Looijmans
>
>
>
>
>
--
Best,
Khoi Trinh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57516): https://lists.yoctoproject.org/g/yocto/message/57516
Mute This Topic: https://lists.yoctoproject.org/mt/92332946/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
