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

[Suhail Singh]

Omar Bassam <omar.bassam88@gmail.com> writes:

>> 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.

That not surprising.  As I mentioned in my last:

>> 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.

And as I mentioned in a still older message:

>>>>>> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
>>>>>> g++), the compiler is able to locate the appropriate header files.
>>>>>>
>>>>>> This should be doable without propagating any other inputs.  For example
>>>>>> by ensuring that jpm sets appropriate environment variables (such as
>>>>>> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
>>>>>> invoking the compiler.  If so, that would be the preferred approach.  We
>>>>>> only want to propagate those inputs that are strictly necessary.
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> I look forward to seeing what you come up with in v11 :)

I.e., it's not clear to me that propagating gcc and g++ is necessary.
And if the same can be achieved by passing appropriate environment
variables, why not?  Could you please answer?

Regardless, we are in agreement that the propagation of gcc-toolchain is
not necessary and should be removed.

> 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 am quite confused.  In the v10 I shared, native-search-paths already
includes $SSL_CERT_DIR, whicb if you look at the source is defined as:

#+begin_src scheme
  (define $SSL_CERT_DIR
    (search-path-specification
     (variable "SSL_CERT_DIR")
     (separator #f)                       ;single entry
     (files '("etc/ssl/certs"))))
#+end_src

I am no longer sure what problem you are trying to solve.

-- 
Suhail