On Wed, Oct 18, 2023 at 9:28 AM Mike Crowe <m...@mcrowe.com> wrote:
>
> On Wednesday 18 October 2023 at 09:19:32 -0700, Khem Raj wrote:
> > On Wed, Oct 18, 2023 at 7:29 AM Mike Crowe via lists.openembedded.org
> > <mac=mcrowe....@lists.openembedded.org> wrote:
> > >
> > > I'm trying to work out how we can make use of devtool to make our lives
> > > easier during development. In general it seems to work very well, but the
> > > way that it modifies bblayers.conf to add an absolute path to the
> > > workspace
> > > directory to BBLAYERS is incompatible with that file being held in a Git
> > > repository and shared by multiple users in multiple trees. There's a high
> > > risk that the file will accidentally be committed containing a path that's
> > > only meaningful for a single user in a single source tree. All of our
> > > other
> > > paths in bblayers.conf are relative to a variable that contains the path
> > > to
> > > the top of the source tree.
> > >
> > > I can manually add ${TOPDIR}/workspace to BBLAYERS in bblayers.conf and
> > > commit that, but unfortunately devtool insists on continuing to add the
> > > absolute path since it doesn't know that's the same as
> > > ${TOPDIR}/workspace.
> > >
> > > I can set "workspace_path = workspace" in devtool.conf to use a relative
> > > path, and that superficially works until externalsrc.bbclass gets upset
> > > that the EXTERNALSRC is not an absolute path.
> > >
> > > I've tried teaching devtool to prepend ${TOPDIR} if the workspace
> > > directory
> > > is not absolute when writing bblayers.conf, but it looks like I'd also
> > > need
> > > to do so in many other places.
> > >
> > > My current workaround is just to add ${TOPDIR}/workspace to the committed
> > > bblayers.conf myself and nobble devtool's _enable_workspace_layer with an
> > > early return. This is ugly and we'd have to carry that change around
> > > forever.
> > >
> > > Since I'm clearly swimming against the tide I'm left wondering whether
> > > I've
> > > missed something. Is there a way to use devtool without having an absolute
> > > path to the workspace in bblayers.conf?
> > >
> > > (At the moment I'm still using dunfell, but I looked at current master and
> > > didn't spot anything that looked like it changed this behaviour.)
> >
> > Perhaps an enhancement to not add the path if its already part of BBLAYERS
> > might do it. You might also print a diagnostics about its pre-existence to
> > make
> > sure it's not accidental.
>
> devtool already tries to do that. It doesn't work in this case since the
> code compares the absolute path against the paths in bblayers.conf and
> isn't in a position to expand variables at that point.
yeah it perhaps has to compare the evaluated paths
>
> Thanks.
>
> Mike.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189413):
https://lists.openembedded.org/g/openembedded-core/message/189413
Mute This Topic: https://lists.openembedded.org/mt/102039990/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
