We are interested in building NIF based projects for GRiSP boards. Many libraries compile their NIFs using rebar3 shell hooks that typically call a Makefile. We have an entire custom process to build NIFs for GRiSP that DOES-NOT use the rebar3 compile task to compile NIFs. In our runtime, any common C library dep is shipped in our custom OTP and since we are cross compiling, we never care to have c libraries installed on the user system.
Problem
General purpose libraries are primarily designed to run on the host system and may require c libraries to be installed.
If such library supports GRISP it doesn't have any possible way to detect that is going to be compiled for GRISP. This is problematic for the deploy task. The task depends on the compile task, but such task triggers shell hooks in the deps apps that can call Makefiles that try to compile NIFs for the host system. WE DO NOT CARE ABOUT THEM FAILING, but this is a rebar error and breaks our rebar3 grisp deploy
We have the usecase of the BLAS library that needs CBLAS to be installed on the system to be able to compile its NIFs. The project has another C source file, made specifically for GRiSP that is used by the plugin. We need a way to let the Makefile know to skip the standard compilation.
Solution
Call the compile task inside the deploy task to inject GRiSP specific OS env.
Using the 'shell_hooks_env' option, the plugin can modify the ENV of all shell_hooks that execute around the compile task. This enables any rebar3 dependency to design its shell hooks around GRiSP.
The shell_hooks_env is a new option available on rebar3 main branch, this PR does not break anything but needs a new rebar3 release to work. https://github.com/erlang/rebar3/pull/2830
Context
We are interested in building NIF based projects for GRiSP boards. Many libraries compile their NIFs using rebar3
shell hooksthat typically call a Makefile. We have an entire custom process to build NIFs for GRiSP that DOES-NOT use therebar3 compiletask to compile NIFs. In our runtime, any common C library dep is shipped in our custom OTP and since we are cross compiling, we never care to have c libraries installed on the user system.Problem
General purpose libraries are primarily designed to run on the host system and may require c libraries to be installed. If such library supports GRISP it doesn't have any possible way to detect that is going to be compiled for GRISP. This is problematic for the deploy task. The task depends on the compile task, but such task triggers shell hooks in the deps apps that can call Makefiles that try to compile NIFs for the host system. WE DO NOT CARE ABOUT THEM FAILING, but this is a rebar error and breaks our
rebar3 grisp deployWe have the usecase of the BLAS library that needs CBLAS to be installed on the system to be able to compile its NIFs. The project has another C source file, made specifically for GRiSP that is used by the plugin. We need a way to let the Makefile know to skip the standard compilation.
Solution
Call the compile task inside the deploy task to inject GRiSP specific OS env. Using the 'shell_hooks_env' option, the plugin can modify the ENV of all shell_hooks that execute around the compile task. This enables any rebar3 dependency to design its shell hooks around GRiSP.
The
shell_hooks_envis a new option available on rebar3 main branch, this PR does not break anything but needs a new rebar3 release to work. https://github.com/erlang/rebar3/pull/2830