* chicken scheme @ 2016-06-30 19:11 John J Foerch 2016-06-30 21:27 ` Ludovic Courtès 0 siblings, 1 reply; 14+ messages in thread From: John J Foerch @ 2016-06-30 19:11 UTC (permalink / raw) To: help-guix Hello, I ran into some problems when installing CHICKEN Scheme on my new GuixSD system. After installing the chicken package, 'chicken-install' failed because gcc was not found on the system. In the package definition for chicken, gcc is listed as a native-input, but from what I understand it should either be a regular input or a propagated-input, because CHICKEN uses gcc to compile scheme programs. I installed gcc separately, and then a test of chicken-install produced this error: linux/limits.h: No such file or directory #include <linux/limits.h> I was testing chicken-install with this command: $ chicken-install matchable -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-06-30 19:11 chicken scheme John J Foerch @ 2016-06-30 21:27 ` Ludovic Courtès 2016-06-30 21:43 ` John J Foerch 2016-06-30 22:05 ` John J Foerch 0 siblings, 2 replies; 14+ messages in thread From: Ludovic Courtès @ 2016-06-30 21:27 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix Hi, John J Foerch <jjfoerch@earthlink.net> skribis: > I ran into some problems when installing CHICKEN Scheme on my new GuixSD > system. After installing the chicken package, 'chicken-install' failed > because gcc was not found on the system. In the package definition for > chicken, gcc is listed as a native-input, but from what I understand it > should either be a regular input or a propagated-input, because CHICKEN > uses gcc to compile scheme programs. Good point. Perhaps CHICKEN should keep references to the GCC toolchain that was used to build it, or propagate it. OTOH, it can in theory use whatever GCC that it finds in $PATH, and people using the interpreter don’t need GCC, which would be an argument in favor of the status quo. Thoughts? > I installed gcc separately, and then a test of chicken-install produced > this error: > > linux/limits.h: No such file or directory #include <linux/limits.h> > > I was testing chicken-install with this command: > > $ chicken-install matchable Could you run: guix package -r gcc -i gcc-toolchain and try again? The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper around ‘ld’ (it makes sure every library linked against is added to the RUNPATH.) Thanks for reporting the issue, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-06-30 21:27 ` Ludovic Courtès @ 2016-06-30 21:43 ` John J Foerch 2016-07-01 9:36 ` Ludovic Courtès 2016-06-30 22:05 ` John J Foerch 1 sibling, 1 reply; 14+ messages in thread From: John J Foerch @ 2016-06-30 21:43 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > Hi, > > John J Foerch <jjfoerch@earthlink.net> skribis: > >> I ran into some problems when installing CHICKEN Scheme on my new GuixSD >> system. After installing the chicken package, 'chicken-install' failed >> because gcc was not found on the system. In the package definition for >> chicken, gcc is listed as a native-input, but from what I understand it >> should either be a regular input or a propagated-input, because CHICKEN >> uses gcc to compile scheme programs. > > Good point. Perhaps CHICKEN should keep references to the GCC toolchain > that was used to build it, or propagate it. OTOH, it can in theory use > whatever GCC that it finds in $PATH, and people using the interpreter > don’t need GCC, which would be an argument in favor of the status quo. > > Thoughts? > >> I installed gcc separately, and then a test of chicken-install produced >> this error: >> >> linux/limits.h: No such file or directory #include <linux/limits.h> >> >> I was testing chicken-install with this command: >> >> $ chicken-install matchable > > Could you run: > > guix package -r gcc -i gcc-toolchain > > and try again? > > The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper > around ‘ld’ (it makes sure every library linked against is added to the > RUNPATH.) > > Thanks for reporting the issue, > Ludo’. Hello Ludovic, Installing gcc-toolchain helped, and there are no more compilation errors. Another error came up in trying to install the built files. Here is my log: $ chicken-install matchable retrieving ... connecting to host "chicken.kitten-technologies.co.uk", port 80 ... requesting "/henrietta.cgi?name=matchable&mode=default" ... reading response ... HTTP/1.1 200 OK Date: Thu, 30 Jun 2016 21:36:20 GMT Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6 Connection: close Transfer-Encoding: chunked Content-Type: text/plain reading chunks ... reading files ... ./match-simple.scm ./match.scm ./matchable-test.scm ./matchable.meta ./matchable.scm ./matchable.setup matchable located at /tmp/temp112c.2170/matchable checking platform for `matchable' ... checking dependencies for `matchable' ... install order: ("matchable") installing matchable:3.6 ... changing current directory to /tmp/temp112c.2170/matchable '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.scm -j matchable '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.import.scm cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so' cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system Error: shell command failed with nonzero exit status 256: cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so' Error: shell command terminated with nonzero exit code 17920 "'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu... -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-06-30 21:43 ` John J Foerch @ 2016-07-01 9:36 ` Ludovic Courtès 2016-07-01 12:11 ` John J Foerch 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2016-07-01 9:36 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix John J Foerch <jjfoerch@earthlink.net> skribis: > Installing gcc-toolchain helped, and there are no more compilation > errors. Another error came up in trying to install the built files. > Here is my log: > > $ chicken-install matchable > retrieving ... > connecting to host "chicken.kitten-technologies.co.uk", port 80 ... > requesting "/henrietta.cgi?name=matchable&mode=default" ... > reading response ... > HTTP/1.1 200 OK > Date: Thu, 30 Jun 2016 21:36:20 GMT > Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6 > Connection: close > Transfer-Encoding: chunked > Content-Type: text/plain > reading chunks ... > reading files ... > ./match-simple.scm > ./match.scm > ./matchable-test.scm > ./matchable.meta > ./matchable.scm > ./matchable.setup > matchable located at /tmp/temp112c.2170/matchable > checking platform for `matchable' ... > checking dependencies for `matchable' ... > install order: > ("matchable") > installing matchable:3.6 ... > changing current directory to /tmp/temp112c.2170/matchable > '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup' > '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.scm -j matchable > '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode -s -O3 -d0 matchable.import.scm > cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so' > cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system > > Error: shell command failed with nonzero exit status 256: > > cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so' > > > Error: shell command terminated with nonzero exit code > 17920 > "'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu... I think we need to build CHICKEN such that it uses /var/lib instead of /gnu/store/…-chicken/var/lib (the latter is immutable.) I suppose that’s how it works on other distros, right? (With this approach only root can install software, though.) Do you know how to make this change? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 9:36 ` Ludovic Courtès @ 2016-07-01 12:11 ` John J Foerch 2016-07-01 13:27 ` Thompson, David 2016-07-01 19:52 ` Ludovic Courtès 0 siblings, 2 replies; 14+ messages in thread From: John J Foerch @ 2016-07-01 12:11 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > John J Foerch <jjfoerch@earthlink.net> skribis: > >> Installing gcc-toolchain helped, and there are no more compilation >> errors. Another error came up in trying to install the built files. >> Here is my log: >> >> <SNIP> > > I think we need to build CHICKEN such that it uses /var/lib instead of > /gnu/store/…-chicken/var/lib (the latter is immutable.) I suppose > that’s how it works on other distros, right? (With this approach only > root can install software, though.) > > Do you know how to make this change? > > Thanks, > Ludo’. First a question about /var/lib, and please excuse the newbie question. If chicken extensions were installed to /var/lib, wouldn't that go against the spirit of guix of keeping every program isolated? Isn't /var/lib global state? I have just learned about 'guix import', and have the thought that a package importer would be the better way to go. Eventually I would like to package software that I've written in CHICKEN for GuixSD, and only a package importer would make that feasible. I will definitely give it a try to add such a feature to guix, and will follow whatever advice you may have. In some ways I am still learning the very basics of guix, so it may take me a bit to get up to speed. Thank you, -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 12:11 ` John J Foerch @ 2016-07-01 13:27 ` Thompson, David 2016-07-01 19:52 ` Ludovic Courtès 1 sibling, 0 replies; 14+ messages in thread From: Thompson, David @ 2016-07-01 13:27 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote: > First a question about /var/lib, and please excuse the newbie question. > If chicken extensions were installed to /var/lib, wouldn't that go > against the spirit of guix of keeping every program isolated? Isn't > /var/lib global state? Yes, but this program is not Guix. It's a completely separate package manager, and it should work as intended. - Dave ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 12:11 ` John J Foerch 2016-07-01 13:27 ` Thompson, David @ 2016-07-01 19:52 ` Ludovic Courtès 2016-07-01 20:22 ` John J Foerch 1 sibling, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2016-07-01 19:52 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix John J Foerch <jjfoerch@earthlink.net> skribis: > I have just learned about 'guix import', and have the thought that a > package importer would be the better way to go. Eventually I would like > to package software that I've written in CHICKEN for GuixSD, and only a > package importer would make that feasible. "Thompson, David" <dthompson2@worcester.edu> skribis: > On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote: > >> First a question about /var/lib, and please excuse the newbie question. >> If chicken extensions were installed to /var/lib, wouldn't that go >> against the spirit of guix of keeping every program isolated? Isn't >> /var/lib global state? > > Yes, but this program is not Guix. It's a completely separate package > manager, and it should work as intended. Agreed. So I think there are two issues at hand: 1. How to arrange our ‘chicken’ package so that ‘chicken-install’ works as intended. 2. How to import Eggs so that they can be first-class Guix packages. #2, which means writing an importer, is definitely the most profitable approach: It’s best as a user to have all the packages managed by the same tool, especially if that provides isolation, transactional upgrades and rollbacks, etc. #1 is useful for CHICKEN users who are used to ‘chicken-install’ (similarly pip, npm, etc. are supposed to work.) It should work in the same way as on other distros. I’ve never used it though, so I can’t give precise advice. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 19:52 ` Ludovic Courtès @ 2016-07-01 20:22 ` John J Foerch 2016-07-02 10:21 ` Ludovic Courtès 0 siblings, 1 reply; 14+ messages in thread From: John J Foerch @ 2016-07-01 20:22 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > John J Foerch <jjfoerch@earthlink.net> skribis: > >> I have just learned about 'guix import', and have the thought that a >> package importer would be the better way to go. Eventually I would like >> to package software that I've written in CHICKEN for GuixSD, and only a >> package importer would make that feasible. > > "Thompson, David" <dthompson2@worcester.edu> skribis: > >> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote: >> >>> First a question about /var/lib, and please excuse the newbie question. >>> If chicken extensions were installed to /var/lib, wouldn't that go >>> against the spirit of guix of keeping every program isolated? Isn't >>> /var/lib global state? >> >> Yes, but this program is not Guix. It's a completely separate package >> manager, and it should work as intended. > > Agreed. So I think there are two issues at hand: > > 1. How to arrange our ‘chicken’ package so that ‘chicken-install’ > works as intended. > > 2. How to import Eggs so that they can be first-class Guix packages. > > #2, which means writing an importer, is definitely the most profitable > approach: It’s best as a user to have all the packages managed by the > same tool, especially if that provides isolation, transactional upgrades > and rollbacks, etc. > > #1 is useful for CHICKEN users who are used to ‘chicken-install’ > (similarly pip, npm, etc. are supposed to work.) It should work in the > same way as on other distros. I’ve never used it though, so I can’t > give precise advice. > It installs all extensions to a single system-wide directory, with one path component that gives the binary version. On my debian machine, that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is simpler than something like npm. -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 20:22 ` John J Foerch @ 2016-07-02 10:21 ` Ludovic Courtès 2016-07-17 14:22 ` John J Foerch 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2016-07-02 10:21 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix John J Foerch <jjfoerch@earthlink.net> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> John J Foerch <jjfoerch@earthlink.net> skribis: >> >>> I have just learned about 'guix import', and have the thought that a >>> package importer would be the better way to go. Eventually I would like >>> to package software that I've written in CHICKEN for GuixSD, and only a >>> package importer would make that feasible. >> >> "Thompson, David" <dthompson2@worcester.edu> skribis: >> >>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote: >>> >>>> First a question about /var/lib, and please excuse the newbie question. >>>> If chicken extensions were installed to /var/lib, wouldn't that go >>>> against the spirit of guix of keeping every program isolated? Isn't >>>> /var/lib global state? >>> >>> Yes, but this program is not Guix. It's a completely separate package >>> manager, and it should work as intended. >> >> Agreed. So I think there are two issues at hand: >> >> 1. How to arrange our ‘chicken’ package so that ‘chicken-install’ >> works as intended. >> >> 2. How to import Eggs so that they can be first-class Guix packages. >> >> #2, which means writing an importer, is definitely the most profitable >> approach: It’s best as a user to have all the packages managed by the >> same tool, especially if that provides isolation, transactional upgrades >> and rollbacks, etc. >> >> #1 is useful for CHICKEN users who are used to ‘chicken-install’ >> (similarly pip, npm, etc. are supposed to work.) It should work in the >> same way as on other distros. I’ve never used it though, so I can’t >> give precise advice. >> > > It installs all extensions to a single system-wide directory, with one > path component that gives the binary version. On my debian machine, > that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is > simpler than something like npm. Right. So to address #1, we should make sure it uses /var/lib, as discussed earlier. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-02 10:21 ` Ludovic Courtès @ 2016-07-17 14:22 ` John J Foerch 2016-07-17 17:45 ` Ludovic Courtès 0 siblings, 1 reply; 14+ messages in thread From: John J Foerch @ 2016-07-17 14:22 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > John J Foerch <jjfoerch@earthlink.net> skribis: > >> ludo@gnu.org (Ludovic Courtès) writes: >> >>> John J Foerch <jjfoerch@earthlink.net> skribis: >>> >>>> I have just learned about 'guix import', and have the thought that a >>>> package importer would be the better way to go. Eventually I would like >>>> to package software that I've written in CHICKEN for GuixSD, and only a >>>> package importer would make that feasible. >>> >>> "Thompson, David" <dthompson2@worcester.edu> skribis: >>> >>>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote: >>>> >>>>> First a question about /var/lib, and please excuse the newbie question. >>>>> If chicken extensions were installed to /var/lib, wouldn't that go >>>>> against the spirit of guix of keeping every program isolated? Isn't >>>>> /var/lib global state? >>>> >>>> Yes, but this program is not Guix. It's a completely separate package >>>> manager, and it should work as intended. >>> >>> Agreed. So I think there are two issues at hand: >>> >>> 1. How to arrange our ‘chicken’ package so that ‘chicken-install’ >>> works as intended. >>> >>> 2. How to import Eggs so that they can be first-class Guix packages. >>> >>> #2, which means writing an importer, is definitely the most profitable >>> approach: It’s best as a user to have all the packages managed by the >>> same tool, especially if that provides isolation, transactional upgrades >>> and rollbacks, etc. >>> >>> #1 is useful for CHICKEN users who are used to ‘chicken-install’ >>> (similarly pip, npm, etc. are supposed to work.) It should work in the >>> same way as on other distros. I’ve never used it though, so I can’t >>> give precise advice. >>> >> >> It installs all extensions to a single system-wide directory, with one >> path component that gives the binary version. On my debian machine, >> that is /var/lib/chicken/7 (for chicken 4.10.0). In that way, it is >> simpler than something like npm. > > Right. So to address #1, we should make sure it uses /var/lib, as > discussed earlier. > I'm finally getting back to this. One point about chicken is that it does not support multiple extension directories, only one. They go into <VARDIR>/chicken/<BINARY-VERSION>. This introduces a difficulty because if VARDIR is /var/lib, then the default extensions (that come with chicken) get installed to a global directory. The chicken-install system will then work, but in the future when we add a package importer, imported packages would also go into this global directory. If on the other hand, VARDIR is (string-append out "/var/lib") the default extensions and imported extensions go to the right place, but manual chicken-install cannot write to that location. Any further thoughts on this, given that information? -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-17 14:22 ` John J Foerch @ 2016-07-17 17:45 ` Ludovic Courtès 0 siblings, 0 replies; 14+ messages in thread From: Ludovic Courtès @ 2016-07-17 17:45 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix Hello! John J Foerch <jjfoerch@earthlink.net> skribis: > I'm finally getting back to this. One point about chicken is that it > does not support multiple extension directories, only one. They go into > <VARDIR>/chicken/<BINARY-VERSION>. This introduces a difficulty because > if VARDIR is /var/lib, then the default extensions (that come with > chicken) get installed to a global directory. The chicken-install > system will then work, but in the future when we add a package importer, > imported packages would also go into this global directory. > > If on the other hand, VARDIR is (string-append out "/var/lib") the > default extensions and imported extensions go to the right place, but > manual chicken-install cannot write to that location. > > Any further thoughts on this, given that information? Ouch, that’s a problem. Nixpkgs uses VARDIR=OUT/var/lib, meaning that chicken-install does not work. However, it also contains an optional patch that allows extensions to be searched for elsewhere: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/chicken/0001-Introduce-CHICKEN_REPOSITORY_EXTRA.patch I think the best course of action would be to submit this change upstream, if it hasn’t been done already. It’s useful beyond Nix and Guix, so it probably makes sense to include it. In the meantime, I would (temporarily) sacrifice chicken-install in favor of an Egg importer. WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-06-30 21:27 ` Ludovic Courtès 2016-06-30 21:43 ` John J Foerch @ 2016-06-30 22:05 ` John J Foerch 2016-07-01 9:39 ` Ludovic Courtès 1 sibling, 1 reply; 14+ messages in thread From: John J Foerch @ 2016-06-30 22:05 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > > Good point. Perhaps CHICKEN should keep references to the GCC toolchain > that was used to build it, or propagate it. OTOH, it can in theory use > whatever GCC that it finds in $PATH, and people using the interpreter > don’t need GCC, which would be an argument in favor of the status quo. > > Thoughts? > I don't have enough experience with guix to give definite advice on this, but chicken does present a couple of unique issues. I think that having gcc available is essential to chicken's purpose, as one is not likely to only use the interpreter. Installing extensions requires C compilation, and if one is not installing extensions and not using chicken's compiler, then one might as well be using any old scheme off the street ;-) If the gcc-toolchain were kept in reference (but not in the profile), that may be enough. The chicken compiler has options (and/or environment variables) to use another gcc if desired, so people who want to use another gcc than the one used to build chicken can still do so. Some chicken extensions install executable programs (for example hyde). On other OSes they would normally be installed to /usr/local/bin. Obviously this would be different for guix. -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-06-30 22:05 ` John J Foerch @ 2016-07-01 9:39 ` Ludovic Courtès 2016-07-01 12:16 ` John J Foerch 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2016-07-01 9:39 UTC (permalink / raw) To: John J Foerch; +Cc: help-guix John J Foerch <jjfoerch@earthlink.net> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > I don't have enough experience with guix to give definite advice on > this, but chicken does present a couple of unique issues. I think that > having gcc available is essential to chicken's purpose, as one is not > likely to only use the interpreter. Installing extensions requires C > compilation, and if one is not installing extensions and not using > chicken's compiler, then one might as well be using any old scheme off > the street ;-) Right, makes sense. :-) > If the gcc-toolchain were kept in reference (but not in the profile), > that may be enough. The chicken compiler has options (and/or > environment variables) to use another gcc if desired, so people who want > to use another gcc than the one used to build chicken can still do so. OK. Then I guess we should adjust our ‘chicken’ package so that it hard-codes the absolute file name of ‘gcc’ and ‘ld’. Would you like to give it a try? > Some chicken extensions install executable programs (for example > hyde). On other OSes they would normally be installed to > /usr/local/bin. Obviously this would be different for guix. This part doesn’t sound Guix-dependent. It’s more about whether non-root users can install to, say, ~/.local, or whether only root can install (to /usr/local/bin or similar.) WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: chicken scheme 2016-07-01 9:39 ` Ludovic Courtès @ 2016-07-01 12:16 ` John J Foerch 0 siblings, 0 replies; 14+ messages in thread From: John J Foerch @ 2016-07-01 12:16 UTC (permalink / raw) To: help-guix ludo@gnu.org (Ludovic Courtès) writes: > John J Foerch <jjfoerch@earthlink.net> skribis: > >> ludo@gnu.org (Ludovic Courtès) writes: >> I don't have enough experience with guix to give definite advice on >> this, but chicken does present a couple of unique issues. I think that >> having gcc available is essential to chicken's purpose, as one is not >> likely to only use the interpreter. Installing extensions requires C >> compilation, and if one is not installing extensions and not using >> chicken's compiler, then one might as well be using any old scheme off >> the street ;-) > > Right, makes sense. :-) > >> If the gcc-toolchain were kept in reference (but not in the profile), >> that may be enough. The chicken compiler has options (and/or >> environment variables) to use another gcc if desired, so people who want >> to use another gcc than the one used to build chicken can still do so. > > OK. Then I guess we should adjust our ‘chicken’ package so that it > hard-codes the absolute file name of ‘gcc’ and ‘ld’. Would you like to > give it a try? > Sure! >> Some chicken extensions install executable programs (for example >> hyde). On other OSes they would normally be installed to >> /usr/local/bin. Obviously this would be different for guix. > > This part doesn’t sound Guix-dependent. It’s more about whether > non-root users can install to, say, ~/.local, or whether only root can > install (to /usr/local/bin or similar.) WDYT? > Sorry, I don't really understand the issues at hand well enough yet to comment. I have been looking at 'guix import', as I said in my other message, and I now wonder if a package importer is the best way forward, in accordance with the guix spirit. -- John Foerch ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-07-17 17:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-30 19:11 chicken scheme John J Foerch 2016-06-30 21:27 ` Ludovic Courtès 2016-06-30 21:43 ` John J Foerch 2016-07-01 9:36 ` Ludovic Courtès 2016-07-01 12:11 ` John J Foerch 2016-07-01 13:27 ` Thompson, David 2016-07-01 19:52 ` Ludovic Courtès 2016-07-01 20:22 ` John J Foerch 2016-07-02 10:21 ` Ludovic Courtès 2016-07-17 14:22 ` John J Foerch 2016-07-17 17:45 ` Ludovic Courtès 2016-06-30 22:05 ` John J Foerch 2016-07-01 9:39 ` Ludovic Courtès 2016-07-01 12:16 ` John J Foerch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).