[bug#72925] [PATCH v10] gnu: Add jpm.

[Omar Bassam <omar.bassam88@gmail.com>]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Omar Bassam <omar.bassam88@gmail.com> writes:
>
>>>> I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
>>>> commands and the "jpm build" commands worked fine for me without any
>>>> issues. I didn't need to set up any C related environemnt variables.
>>>> What kind of error where you getting? 
>>>
>>> I am unable to get the exact message at the moment (due to non-technical
>>> and unrelated reasons), but it was some missing header file.
>>>
>>> As I mentioned in the quoted message above, however, what would be
>>> better than propagating gcc, g++ etc would be to ensure that jpm passes
>>> appropriate flags when invoking them.  Have you looked into that?
>>>
>>
>> I am not really an expert in compiling C programs so I'm not sure what
>> would be the best way to verify this? the "jpm build" command ran fine
>> for me and I don't have any of those C*PATH environment variables set.
>
> When gcc-toolchain is excluded from propagated-inputs, and neither gcc
> nor g++ is in propagated-inputs (i.e., propagated-inputs only contains
> janet), you *don't* observe a build failure in a _pure_ container where
> nss-certs is available while evaluating "jpm install -l sh"?
>
> If so, please let me know and I shall try and reproduce the error I
> experienced.

Sorry, I didn't fully explain. I meant that instead of doing this
module-ref expression to include "gcc-toolchain", I simply included
"gcc" (which is already imported in lisp.scm) in the propagated-inputs
and it worked fine (in a pure container) for both the "jpm install" and
the "jpm build" command.

>
> If not, and you are simply stating that things work by propagating gcc
> and g++, then we are talking about different things.  Specifically, I
> was considering what would be needed for eliminating gcc and g++ from
> propagated-inputs.
>
>> Is it possible to set a default value for that environment variable?
>
> Since you already set $JANET_HEADERPATH and $JANET_LIBPATH via
> wrap-program, I am not sure I understand the complication you're running
> into while trying to provide a default for $SSL_CERT_DIR.

So you think the following would make sense as a sane default for the
"SSL_CERT_DIR" env variables as an example?

#+begin_src scheme
 (native-search-paths
   (list (search-path-specification
          (variable "SSL_CERT_DIR")
          (files (list "/etc/ssl/certs/")))))
#+end_src

I'm not sure what would be a good default for "SSL_CERT_FILE" though.

Thanks,
Omar