On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 11:15:40AM -0400, Robert P. J. Day wrote:
> > On Fri, 28 May 2021, Quentin Schulz wrote:
> >
> > > On Fri, May 28, 2021 at 10:47:30AM -0400, Robert P. J. Day wrote:
> > > > On Fri, 28 May 2021, Quentin Schulz wrote:
> > > >
> > > > > On Fri, May 28, 2021 at 09:57:26AM -0400, Robert P. J. Day wrote:
> > > > > > On Fri, 28 May 2021, Quentin Schulz wrote:
> > > > > >
> > > > > > > On Fri, May 28, 2021 at 08:51:51AM -0400, Robert P. J. Day wrote:
> > > > > > > >
> > > > > > > > as a short followup to my earlier note about creating a bunch
> > > > > > > > of
> > > > > > > > externalsrc-based recipes to demonstrate their proper
> > > > > > > > structure, it's
> > > > > > > > easy to add the recipe files to a layer, but i then realized i
> > > > > > > > needed
> > > > > > > > to figure out where to put the corresponding source, and how i
> > > > > > > > would
> > > > > > > > refer to it with the EXTERNALSRC variable, and after some
> > > > > > > > thought, it
> > > > > > > > occurred that the simplest solution is to simply put the source
> > > > > > > > in a
> > > > > > > > "src" subdirectory next to the recipe itself, and use:
> > > > > > > >
> > > > > > > > inherit externalsrc
> > > > > > > >
> > > > > > > > EXTERNALSRC = "${THISDIR}/src"
> > > > > > >
> > > > > > > FWIW, we use multiple ../ in the variable and it works just fine.
> > > > > > > Might be a slightly better example than having it next to the
> > > > > > > recipe, since this would actually be covered by SRC_URI =
> > > > > > > "file://whatever". In that case, you could add the sources in
> > > > > > > `yocto-docs/externalsrc-src` for example?
> > > > > >
> > > > > > after further cogitation, it seems like using SRC_URI might be the
> > > > > > way to go after all, unless i drastically misunderstand some
> > > > > > features
> > > > > > of "externalsrc".
> > > > > >
> > > > > > at the moment, most of this external source has to be compiled in
> > > > > > place; very little of it supports "out of tree" building, which
> > > > > > means
> > > > > > that i'm forced to(?):
> > > > >
> > > > > What make you say that? Links, sources? By default it builds in the
> > > > > usual ${WORKDIR}/${BPN}-${PV}.
> > > >
> > > > i know, but if i do this with the source example i'm playing with:
> > > >
> > > > EXTERNALSRC = "${THISDIR}/src"
> > > > # EXTERNALSRC_BUILD = "${EXTERNALSRC}"
> > > >
> > > > and let EXTERNALSRC_BUILD default to the value you identify, i get:
> > > >
> > > > | make: *** No rule to make target 'install'. Stop.
> > > >
> > > > i clearly don't understand something fundamental about using
> > > > externalsrc -- how do i get that external, remote source to build
> > > > under WORKDIR?
> > > >
> > >
> > > Would you mind sharing your work so far (recipe + source)? So we can
> > > try to reproduce on our side? I have a very complex recipe without
> > > EXTERNALSRC_BUILD set (on thud though, but with some backports from
> > > later versions for the externalsrc class).
> > >
> > > I couldn't find tests for externalsrc recipes, so either I'm blind
> > > (can't exclude it) or we're missing such tests, which we should add
> > > :)
> >
> > i'm just using dmidecode as grabbed from here:
> >
> > http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/dmidecode/dmidecode_3.3.bb?h=master
> >
> > but let me ask a fairly basic question that might clear this up.
> >
> > AIUI (and lord knows i could be wrong), depending on the
> > structure of the Makefile for some blob of source, it may not be
> > possible to build that source "out of tree". unless you've built
> > that sort of functionality into the Makefile, then you have no
> > choice but to do the build in the source tree. as in, ${B} = ${S}.
> >
> > based on what i see, the dmidecode source must be built in-tree
> > -- there is no functionality in the Makefile to support
> > out-of-tree building. so if i use externalsrc with dmidecode, then
> > the build *must* happen in the source directory i identify with
> > EXTERNALSRC.
>
> ${B} = ${S} by default, so that might explain why it works without
> externalsrc being inherited.
>
> You can see in the makefile that this is assumed. Only the install
> tasks are installing somewhere else (DESTDIR), c.f.
> https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/Makefile
>
> So yes, except if you patch the Makefile to support out-of-tree
> build, you would need both EXTERNALSRC and EXTERNALSRC_BUILD set to
> the same value.
exactly, which is why if one is saddled with source directories that
can't build out-of-tree, then using externalsrc for any of those
directories if multiple developers are trying to build at the same
time would crash and burn in short order as they stepped all over each
other; hence, the need to back off and use SRC_URI in cases like that.
> Maybe a Cmake example would suit better since B is set to
> "${WORKDIR}/build" by default?
>
> Otherwise, write a proper Makefile that allows out-of-tree builds
> for the example :)
nice idea if you have the kind of authority that allows you to
dictate how developers develop. :-) ok, i think we've resolved this.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152394):
https://lists.openembedded.org/g/openembedded-core/message/152394
Mute This Topic: https://lists.openembedded.org/mt/83147632/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-