Inject GRiSP shell hooks env on deploy #76
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
ziopio
force-pushed
the
ziopio/grisp-compile
branch
from
121d293
to
3e944cd
Compare
ziopio
force-pushed
the
ziopio/grisp-compile
branch
from
3e944cd
to
271d43b
Compare
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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. erlang/rebar3#2830