[Nix-dev] buildInputs vs buildNativeInputs

[Nicolas Pierron]

Hi,

On Mon, Aug 27, 2012 at 4:40 AM, Mathijs Kwik <mathijs at bluescreen303.nl> wrote:
> On Mon, Aug 27, 2012 at 1:18 PM, Shea Levy <shea at shealevy.com> wrote:
>> On 08/27/2012 07:12 AM, Mathijs Kwik wrote:
>>>
>>> Hi all,
>>>
>>> I understand the difference between buildInputs and buildNativeInputs,
>>> but I'm not quite sure how to figure out when an input should be
>>> native.
>>
>>
>> The question is, when is the machine code provided by the input executed? If
>> it's at build time (e.g. you execute 'perl' to run a build script), it's a
>> buildNativeInput. If it's at run time (e.g. a linked-to library), it's a
>> buildInput. The reason for this is cross-compilation: buildNativeInputs are
>> host versions of the package, buildInputs are target versions of the
>> package.
>
> I understand that part.
> I recognize a few easy targets like documentation-builders that I know
> run at build-time, but for other inputs it's not always clear.
> As I'm not an expert on the build-process of most packages, I was
> hoping there is some easy trick to find out when the input is needed.
>
> For example, can I just try to move stuff from buildInputs to
> buildNativeInputs one by one? Or some other procedure to try?
>
> Or doesn't it matter a lot most of the time?

Unless you plan to use a cross-compiled version you should not care
much.  If somebody wants a cross-compiled version of your software he
will do the work.  In addition, if you are not cross-compiling, then
you have no good way to check if this is correct or not.  Viric used
to cross compiled for ARM and use qemu for testing the cross-compiled
tools.  This is a clever way for testing, but we would need a
step-by-step process explaining all of that before asking everybody to
handle them correctly (knowing that not all packages can be
cross-compiled).

Cheers,
Sorry for the late answer.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/