On Thu, 05 Dec 2019 15:32:23 +0100 Pierre Neidhardt <m...@ambrevar.xyz> wrote:
> Thanks! > > The first 5 commits look good overall. Good to know. > For the last one, I think there are a few confusions: > > - native-inputs takes packages or origins, it does not take a lambda. > > - To call a custom function from the builder, you need to include the > module that defines it for the build system, e.g. > > (arguments > `(#:modules ((gnu packages telephony) > ,@%gnu-build-system-modules) > ...) > > - In this particular case, you could even make a macro that is > expanded at definition time, so that you would not even need to > import the module. If you don't know how to write scheme macros, no > need to go down this road for now. I read about macros, but didn't write anything complicated myself. I would have to reread the manual again. > But before fixing this issue, what are you trying to do exactly? > Do you intend to reuse this `jami-apply-dependency-patches' procedure > somewhere else? Jami developers apply many patches for different projects - currently our package code only patches pjproject, but ffmpeg needs patches for instance for auto bitrate support and I don't really know what has to be patched next - I listed the output of "find -name "*.patch"" in the first mail. I think copying and pasting similar code from pjproject package definition to ffmpeg definition isn't a good practice, that's why I decided to create a procedure taking patches from ring-project/daemon/contrib/<dependency-name> and applying them. > > On a different topic, to avoid sending patch archives in the future, > you could use a public repository clone of Guix. > There are a couple of free services out there, like sr.ht, maybe > gogs.io, etc. > This would make it smoother to track your progress and help you in > the process. I'll check this out, thanks. Jan Wielkiewicz
