Re: [OE-core] Using devtool without an absolute path to the workspace in bblayers.conf

[Mike Crowe <mac@mcrowe.com>]

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.com@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.

Thanks.

Mike.