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 <suhailsingh247@gmail.com> wrote:

Omar Bassam <omar.bassam88@gmail.com> 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