Hi Suhail, I really need some help here. I am having trouble using gcc-toolchain because when I add the (gnu packages commencement) modules to the lisp.scm file I get a lot of errors that I don't understand. I was able to create a local manifest file with the definition of my package and made the substitutions you suggested and added the propagated input and it worked fine. The issue that I'm having now is to include it in the lisp.scm file. Can you tell what's the right use-module form I need to use? On Thu, 3 Oct 2024 at 16:40, Suhail Singh wrote: > Omar Bassam writes: > > > I just have some questions before submitting v8 if you don't mind. just > to > > make sure I understand correctly. > > Questions are always welcome :) > > >> Specifically, in the file "configs/linux_config.janet", among other > >> things, the below are set > >> > >> #+begin_src janet > >> :c++ "c++" > >> :c++-link "c++" > >> :cc "cc" > >> :cc-link "cc" > >> #+end_src > >> > >> Since Guix, as far as I know, doesn't have packages that provide c++ nor > >> cc, I believe the above need to be patched to refer to gcc and g++ > >> respectively. > >> > >> So we need to substitute the above "c++" and "cc" in the > > "configs/linux_config.janet" to point to the absolute path for the gcc > and > > g++ packages? > > I believe there are multiple ways to make this work. I haven't tested > this, so take my opinions as speculative. > > If we replace "cc" and "c++" with the _absolute path_ for "gcc" and > "g++" respectively from the Guix store, then I don't think we need to > specify gcc-toolchain as a propagated input. Upon reflecting on this, > this is probably the better approach. > > If, however, we replace "cc" and "c++" with the _strings_ "gcc" and > "g++", then I believe we may need to specify gcc-toolchain in the > propagated inputs. IIUC, in this case we would replace the command that > JPM invokes when building. By additionally having gcc-toolchain in the > propagated inputs we'll ensure that they're available in the PATH. > > > Should we also replace other commands that are hard-coded like "cp" and > > "chown" from coreutils the same way I did in my first initial patch? > > I don't believe this is necessary. There's a question regd. whether or > not coreutils needs to be added to the propagated inputs, however. I > don't have a definitive answer, but the way to test it would be to run > it in a pure container and see if things work without having to > explicitly specify coreutils. If you're unable to test it, let me know > when you send v8 and I can test it on your behalf. > > For reference, I use something like the below: > #+begin_src sh > guix shell --pure -CPWN \ > -E '.*GTK.*|.*XDG.*|.*DISPLAY.*|TERM|INSIDE_EMACS' \ > -p /path/to/profile > #+end_src > > > Further, I believe JPM should have a few propagated inputs: > >> - gcc-toolchain > >> - curl > >> - git > >> - nss-certs. > >> > >> I understand why we need gcc-toolchain. But why do we need curl, git and > > nss-certs? > > linux_config.janet also specifies: > > #+begin_src janet > ... > :curlpath "curl" > ... > :gitpath "git" > ... > #+end_src > > Whether Guix packaging picks these up automatically or not, I haven't > tested, but it seems for common usage of JPM these dependencies ought to > be available. Similar to the case of "gcc" and "g++", it might be > better to replace these with references to the respective binaries in > the Guix store instead (as opposed to propagating them as I had > previously suggested). > > Regarding nss-certs, it provides certificates for Certification > Authorities which, IIUC, would be relevant for HTTPS URLs (e.g. fetching > dependencies over git+https). > > To summarize, here's what I believe is needed. Add nss-certs to the > propagated inputs, and for the below replace their occurrence in > linux_config.janet with references to binaries in the store: > - cc -> absolute path of gcc > - c++ -> absolute path of g++ > - curl -> absolute path of curl > - git -> absolute path of git > > -- > Suhail >