IRC channel logs
2024-08-23.log
back to list of logs
<taeaad>nckx: https://pastebin.com/raw/cUiH5v6a This was what I was working on. Sorry I didn't post it because I am new to packaging and there is a lot of unnecessary modules there that I am testing for other packages. If I ask too many questions and post too much code then it is a bit counterproductive for others that know already if the question is trivial. I know that the module name should match the file name in general, but in this case I <taeaad>added it because I thought it was necessary to have it in a module. <taeaad>I didn't realise that the imports could be the problem. <taeaad>How did you know to add (arguments (list #:tests? #f)) (native-inputs (list cmake <taeaad> python-scikit-build-core) rather than to have it as propagated inputs or as a module import? <nckx>Hi taeaad. I seem to have confused you, sorry. Guile module imports merely bring variables into scope, but (barring a very few specific shadowing gotchas) won't cause a build to fail and shouldn't even affect the package in any way if you're not using an undeclared variable. If you add (inputs (list foo)), you need to import the module containing that package, but merely importing (gnu packages foo) will have no effect on its own. <nckx>So the two remaining options native-inputs vs. propagated-inputs: both of these things are build tools, so they are run (vs., say, linked) at build time, so they need to be of the build machine architecture even when cross-compiling. <nckx>I see no reason to propagate them. If there were, you'd still add two variants, the native one to run on the build machine and a propagated one for running on the target machine. <taeaad>nckx: Thanks for the explanation. <nckx>Have you been able to use the final result? <nckx>(Just because it builds for me…) <taeaad>Yes, it works for me, thank you. <taeaad>Thank you for taking the time to test it. <taeaad>I'm going to try to see next week if I can move some of my other python packages to the Guix installation. <taeaad>One of the other reasons I thought Guix is a good option is also the CRAN ecosystem around it, which I find somewhat uncommon for R, and thus refreshing. <taeaad>I could build r-adegraphics without edits from the CRAN import.