GNU bug report logs - #72925
Adding JPM package for Janet

Previous Next

Full log

View this message in rfc822 format

From: Omar Bassam <omar.bassam88 <at> gmail.com>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 72925 <at> debbugs.gnu.org, Omar Bassam <omar.bassam88 <at> gmail.com>
Subject: [bug#72925] [PATCH v10] gnu: Add jpm.
Date: Tue, 08 Oct 2024 00:13:03 +0300

Hi Suhail,
I just sent v11 addressing your comments.

> Omar Bassam <omar.bassam88 <at> 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.
>

I've now removed gcc from the propagated-inputs I've tested passing the
gcc to jpm using the --cc flag as follows "jpm build --cc=/path/to/gcc".
I hope I understood your concern correctly this time. If not, please
feel free to add to the patch whatever you think is needed as I'm not a
C compiling expert.

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

Sorry, I now looked at the code and understand what it's doing.

Thanks again,
Omar

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.