You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #20, @ajcasagrande contributed code changes that copied the Kernel v4l2 header files from a specific commit. This provides for a more stable build experience because the code does not depend on the local machine to provide the header files. This is very useful, however @farshidtz pointed out, in the closed PR, that there could be some unforeseen additional issues.
I am opening this issue provide a place to continue discussions on this and also propose additional ways of approaching this problem. There are some valid issues brought forth in the discussion above. I am doing some research to see how other Go projects handle this. What I have seen so far
Project that includes the headers, as is done here
Project that automatically pull a specific version at commit, via submodules
I think there is a middle ground solutions that can be adopted, while avoiding any additional burden for users of this library.
Possible solutions
Manually update header files and pinned to a specific version (as done now)
Creating a simple code gen (Makefile/script) to automates pulling header files for a specified Kernel version.
Will add more proposals as I continue to explore
The text was updated successfully, but these errors were encountered:
In #20, @ajcasagrande contributed code changes that copied the Kernel v4l2 header files from a specific commit. This provides for a more stable build experience because the code does not depend on the local machine to provide the header files. This is very useful, however @farshidtz pointed out, in the closed PR, that there could be some unforeseen additional issues.
I am opening this issue provide a place to continue discussions on this and also propose additional ways of approaching this problem. There are some valid issues brought forth in the discussion above. I am doing some research to see how other Go projects handle this. What I have seen so far
I think there is a middle ground solutions that can be adopted, while avoiding any additional burden for users of this library.
Possible solutions
The text was updated successfully, but these errors were encountered: