Re: Environment variable in .prj file

[Stephen Leake]

Simon Wright <simon.j.wright@mac.com> writes:

> On 24 Jul 2020, at 20:06, Stephen Leake <stephen_leake@stephe-leake.org> 
> wrote:
>> 
>> The issue is what env vars are visible when `substitute-in-file-name' is
>> called. That is currently done in gnatcore.el `wisi-compiler-parse-one',
>> which only includes env vars defined in the project. That's been true
>> since Sept 2019 when I moved to project.el stuff. So you are remembering
>> behavior from before that, when it most likely did use the global
>> process-environment, which includes HOME.
>
> Yes; last changed (but probably not last used, tbf) Feb 2019.
>
>> In wisi.info <http://wisi.info/>, the "Project files" section says:
>> 
>>    A variable name that starts with @code{$} is set as a process
>>    environment variable, for processes launched from Emacs for the
>>    project.
>> 
>>    In values, process environment variables can be referenced
>>    using the normal @code{$var} syntax.
>> 
>> which supports your expectation; HOME is a process env var.
>
> C-h C-v process-environment:
>
> "Entries in this list take precedence to those in the frame-local
> environments.  Therefore, let-binding ‘process-environment’ is an easy
> way to temporarily change the value of an environment variable,
> irrespective of where it comes from.  To use ‘process-environment’ to
> remove an environment variable, include only its name in the list,
> without "=VALUE"."
>
> which doesn't seem to match the actual behaviour.

Right.

The gnat-core code specifically excludes process-environment entirely.
This definitely needs to be explained in wisi.info, and in comments in
the code.

Note that it works the other way as well; $BAR declared in a .prj file
is visible only to that project; it is _not_ in the global
'process-environment'. I think that's the original motivation for this
change; Stefan Monnier complained that GPR_PROJECT_PATH was polluting
the global env var space.

>> I prefer the current implementation; _everything_ needed by the project
>> is defined in the project, so you don't accidently depend on some
>> random file referenced via some random env var (I've been bitten by that
>> many times when moving to another machine) (your next message indicates
>> you discovered this).
>> 
>> But it probably makes sense to have an option somewhere to say "use 
>> process-environment; I accept the risk". In a .prj file, we could have:
>> 
>>    global_env_vars=true
>> 
>> or something similar
>
> Possibly
>
>       import_env_var=HOME

That would allow selecting individual env vars, rather than all; I like
that.

You can do that now by using the :compile-env arg of
wisi-prj-select-cache. For example, in org.wisitoken/build/prj.el I
have:

(wisi-prj-select-cache
 "wisitoken.prj"
 (create-ada-prj
  :name "wisitoken main"
  :compile-env
  '("SAL=../../org.stephe_leake.sal"))
  "Makefile")

In work branches I edit the name, and edit the SAL location to use
corresponding sal branches.

You could use something like:

:compile-env
 (list
   (concat "HOME=" (getenv "HOME"))) ;; Make 'HOME' visible in .prj file.

A little clunky, but it does the job, while still documenting what's
going on.

-- 
-- Stephe