(No subject)

["S. Lockwood-Childs" <sjl@vctlabs.com>]

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