Re: Environment variable in .prj file

[Stephen Leake]

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

> I'm sure I've missed something, but is there a way of completely
> wiping out all traces of current projects? At the moment I have to
> stop/restart emacs

You can try wisi-refresh-prj-cache for the current project, and
wisi-prj-delete for the others. But I often restart emacs to be sure.

> ======================================
> diff --git a/gnat-core.el b/gnat-core.el
> index 5901b223..be008baa 100644
> --- a/gnat-core.el
> +++ b/gnat-core.el
> @@ -86,8 +86,10 @@ Throw an error if current project does not have a 
> gnat-compiler."
>    ;; We maintain two project values for this;
>    ;; project-path - a list of directories, for elisp find file
>    ;; GPR_PROJECT_PATH in environment, for gnat-run
> -  (let ((process-environment (copy-sequence (wisi-prj-file-env project))))
> -    (cl-pushnew dir (gnat-compiler-project-path compiler) :test 
> #'string-equal)
> +  (let ((process-environment (copy-sequence (wisi-prj-file-env project)))
> +        (d (substitute-in-file-name dir)))
> +    (message "adding project dir %s (was %s)" d dir)
> +    (cl-pushnew d (gnat-compiler-project-path compiler) :test #'string-equal)
>  
>      (setenv "GPR_PROJECT_PATH"
>           (mapconcat 'identity
> ======================================

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.

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

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.


To experiment with that, in wisi-compiler-parse-one, change to:

    (let ((process-environment
           (append
            (wisi-prj-compile-env project)
            (wisi-prj-file-env project)
            process-environment)));; reference, for substitute-in-file-name
      (gnat-prj-add-prj-dir project compiler (expand-file-name
         (substitute-in-file-name value)))))

(100% not tested). If you have GPR_PROJECT_PATH defined in your global
environment, you will get confusing results, since that is also defined
for each project (which is another reason to not do this).

-- 
-- Stephe