[oe] (no subject)

[William Delacre]

Le mar. 31 juil. 2018 à 20:42, S. Lockwood-Childs <sjl at vctlabs.com> a
écrit :

> On Tue, Jul 31, 2018 at 10:30:02AM -0400, Mark Asselstine wrote:
> > On Tuesday, July 31, 2018 7:54:22 AM EDT William Delacre wrote:
> > > Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl at vctlabs.com> a
> > >
> > > écrit :
> > > > It depends on the role of the particular dependency:
> > > >
> > > > * tool you need to run during build             <-- native dependency
> > > > * library you need to link against during build <-- target dependency
> > >
> > > Thanks for the precision :-)
> > >
> > > My question may seem a bit stupid but how do you know which is which ?
> > > Let’s say I want to write a recipe to install any specific software on
> my
> > > target, how do I choose the dependencies ?
> > > I have to refer to the software Makefile/CMakeList ?
> >
> > It is not always easy to see via code inspection. I would suggest keep a
> > second build for a different arch than your build host, possibly ARM.
> Start by
> > using the non-native DEPENDS and only if there is an issue with the ARM
> build
> > look at using -native for a DEPENDS.
> >
> > To be honest I haven't had to worry about this too much as it is rare to
> run
> > into issues.
>
> Yes target build dependencies are more common, so this approach of
> defaulting
> to target rather than native does make sense.
>
> My other advice is to start out by reviewing the build instructions in the
> README / INSTALL docs for the software package; if that package requires
> some
> non-standard external build tool ("non-standard" meaning other than
> autotools / make etc) that would need to be listed as native dependency,
> that tool really should be mentioned in the build instructions.
>
> --SJLC


This is exactly what I needed to know ! Thanks you all a lot !

>
>