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. > > Thanks. > > Mike. > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189411): https://lists.openembedded.org/g/openembedded-core/message/189411 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] -=-=-=-=-=-=-=-=-=-=-=-
