Hi Suhail, I just submitted a new path v8. I tested in a pure container shell and it worked for me for the following commands: - "jpm install -l sh" - "jpm install -l spork" - "jpm build" : for a basic hello world project Can you please have another look and let me know if you have any comments Thanks, *Omar* On Fri, 4 Oct 2024 at 01:04, Omar Bassam wrote: > It's OK I figured it out now. I'll be posting the patch soon. > > On Thu, 3 Oct 2024 at 22:45, Omar Bassam wrote: > >> 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 >>> >>