Modularize path to gsi and gsi-script

[00vareladavid]

Fix for #21. It contains all the changes mentioned in #39.

[vyzo]

LGTM

[vyzo]

@fare any comments?

[fare]

I'm in favor of minimizing configuration variables.

[00vareladavid]

@fare I'm not sure I follow. How can we keep the configuration file, but remove the variable? It seems to me that at least one variable is necessary, no?

[vyzo]

I think this one variable is fine; fare was just expressing his general distaste for configuration variables.

[00vareladavid]

I'm looking into making all accesses to gsi more consistent. Perhaps a thin wrapper around gsi will be closer to what @fare is thinking of?

What is the purpose of src/gerbil/gxi-build-script? Is it used for dev purposes? Grepping through the code, it seems only src/std/build-deps-gen.ss requires it. If so, gxi-build-script can be made to a special case of gxi and we can get rid of a whole file (along with its access to gsi).

gsi-script only seems to be used by src/gerbil/runtime/build.scm so it can be easily moved to build.sh. This change would result in a cleaner system at the expense of being slightly less user friendly (an end-user will only need to make a single change, but they have to search through the code a bit to find it).

[vyzo]

gxi-build-script is necessary for deps generation in stdlib, as there is a requirement for gambit kernel symbols (long story short).
References to gsi-script can be dropped.

[00vareladavid]

I have 3 more commits ready:

• Incorporate gxi-build-script into build.sh.
• remove gsi_script variable as described earlier
• replace conf.sh with a thin wrapper around gsi. This means no more need to export a variable while retaining the ability to set the path to gsi at a single point.

I did some basic testing and everything is running fine.

I will adjust the documentation once we settle on a design. I think the 3 additional commits will result in the cleanest design, but I might be missing something. What do you guys think?

[00vareladavid]

The diff is here: master...00vareladavid:dev_gxi

[vyzo]

the hardcoding in the magic is a bad idea i think (cf nixOS), it should go through env..

[vyzo]

Also I am not sure it's an improvement to use a wrapper script, and if we decide to do so can we give it a name without an underscore (gerbil-gsi is much better than gerbil_gsi).

@fare comments?

[00vareladavid]

@vyzo hardcoding what is a bad idea? (what should go through env?)

[vyzo]

meaning it shouldn't be #! gsi-script but rather #!/usr/bin/env gsi-script.

[00vareladavid]

I changed it because it felt like #!/usr/bin/env is misleading, since the build script points the interpreter to the script and so env is never actually called.

I suppose the comments below it should make its purpose clear either way, so I'm not opposed to changing it back

[fare]

If the script can be usefully called independently from the command-line, then the #! is useful. If it should never be called from the command-line, then the #! should be removed.

As for the syntax of the conf file — is the file going to be read by gerbil? Or will the config be baked in the executable? In the former case, the syntax needs to be defined more precisely than that of the shell (e.g. forbidding unescaped $ or ` or ", or some such).

Note that for NixOS, I replace all the #!/usr/bin/env by the hardcoded paths of the actual interpreters under /nix/store/...

[00vareladavid]

@fare There is a case where gsi-script is called something nonstandard (like gsi-script-foo) so:

1. env will not find the interpreter by looking up the name gsi-script
2. the gambit interpreter (regardless of its own executable name) will look at the shebang line purely to determine the correct way to execute the script relevant doc page

The script should not be called from the command line, but the gambit interpreter still expects the shabang.

EDIT:
As for the conf file, wrapping the value single quotes instead of double quotes should prevent any unwanted expansion.

[00vareladavid]

I thought about the 'thin wrapper vs conf file' some more. I concluded that there are no significant technical differences between the two approaches: both allow for a single point of configuration, both introduce a layer of indirection, both require an additional file.

The only significant difference I see is that introducing a conf file will leave the project more susceptible to scope creep, precisely because it introduces a user friendly interface.

I'm ok with either approach. The conf file should be ready in this current PR, but I can push the patch for the wrapper if you guys choose to go that route

[vyzo]

I think I prefer a conf file rather than a wrapper script.

[00vareladavid]

Ok. The latest commit should avoid any confusion about the shebang. This PR should be ready for a merge unless any more changes are necessary.

[00vareladavid]

I don't know if this is still an issue, but FWIW I thought of a cleaner solution.

Essentially replace source conf.sh with GERIBIL_GSI="${GERBIL_GSI-gsi}": it removes the ugliness of having a separate configuration file! (dont know why I didn't think of this back then...)

Anyway, I'll be happy to make the changes myself if/when somebody cares

EDIT: typo in command (now fixed)

[vyzo]

this looks better; let it bake.

[fare]

Shorter and idiomatic:

: ${GERBIL_GSI:=gsi}

Of course, with NixOS, we'd have to bake the full path in the default.

[00vareladavid]

It seems #21 is already fixed by #150